Copyright (C) 1988, 1989, 1990, 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998 Free Software Foundation, Inc.
Published by the Free Software Foundation
59 Temple Place - Suite 330,
Boston, MA 02111-1307 USA
Printed copies are available for $20 each.
ISBN 1-882114-11-6
Permission is granted to make and distribute verbatim copies of
this manual provided the copyright notice and this permission notice
are preserved on all copies.
Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided also that the entire resulting derived work is distributed under the terms of a permission notice identical to this one.
Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions.
GDBのようなデバッガの目的は、 実行中のプログラムの内部において何が起こっているのか、 あるいは、 プログラムがクラッシュした時に何をしていたかを知ることができるようにすることにあります。
GDBは実際のバグを発見するのを手助けするために4つのこと (さらに、 これらを支援するために他のことも) 行います。
GDBを使って C および C++ で記述されたプログラムをデバッグすることができます。 詳細については、 C/C++ を参照してください。
Modula-2 と Chill のサポートはまだ部分的なものです。 Modula-2 に関する情報については、 Modula-2 を参照してください。 Chillに関するドキュメントはまだありません。
集合、 サブ範囲、 ファイル変数、 入れ子関数を使っている Pascal プログラムのデバッグは、 現在のところまだ動作しません。 GDBは Pascal の構文を使った式の入力、 変数の値の表示やそれに類する機能をサポートしません。
GDBは Fortran で記述されたプログラムのデバッグに使うことができます。 しかし、 Fortranの構文を使った式の入力、 変数の値の表示やそれに類する機能はまだサポートされていません。 変数によっては、 末尾のアンダースコアを付けて参照する必要のある場合があります。
GDBはフリー・ソフトウェアであり、 GNU General Public License(GPL)により保護されています。 あなたはGPL によって、 ライセンスされたプログラムをコピーしたり改造したりする自由を与えられます。 しかし、コピーを入手した人は誰でも、 そのコピーとともに、 そのコピーを修正する自由を手に入れますし (つまりソース・コードを入手できなければならないということです)、 また、 さらにそのコピーを配布する自由も手に入れます。 通常、 ソフトウェア会社は、 著作権によりユーザの自由を妨げます。 Free Software Foundation は GPL を使ってこれらの自由を保護します。
根本的には、GPL は、「あなたはこれらの自由を与えられるが、ほかの誰からもこれらの自由を奪うことはできない」と主張するライセンスです。
Richard Stallman は GDB および他の多くの GNU プログラムの最初の開発者です。 ほかにも多くの人々がGDB の開発に貢献してきました。 この節では、 主要な貢献者を紹介したいと思います。 フリー・ソフトウェアの美徳の1つは、 誰もがそれに貢献する自由があるという点です。 残念ながら、 ここですべての人を紹介することはできません。 GDB ディストリビューションに含まれる `ChangeLog' というファイルにおおまかな紹介を載せてあります。
バージョン 2.0 よりもずっと前の変更内容は、いつのまにか紛失してしまいました。
お願い: この節への追加は大歓迎です。 あなたやあなたの友人 (公平を期すため、あなたの敵も加えておきましょう) が不当にもこのリストから除外されているのであれば、 喜んで名前を付け加えます。
彼らの長期に渡る労働が感謝されていないと思われないように、 最初に、 GDB の主要なリリースを通じて GDB の面倒を見てきた人々に特に感謝します。 その人々とは、 Stan Shebs (リリース 4.14)、 Fred Fish (リリース 4.13, 4.12, 4.11, 4.10, 4.9)、 Stu Grossman とJohn Gilmore (リリース 4.8, 4.7, 4.6, 4.5, 4.4)、 John Gilmore (リリース 4.3, 4.2, 4.1, 4.0, 3.9)、 Jim Kingdon (リリース 3.5, 3.4, 3.3)、 Randy Smith (リリース 3.2, 3.1, 3.0) です。 ある期間に渡ってGDBの主要な保守者として仕事をすることで、 彼らは皆、 デバッガ全体の構造、 安定性、 機能に対して重要な貢献をしてくれました。
Richard Stallman は、様々な機会に Peter TerMaat、Chris Hanson、Richard Mlynarik の支援を受けながら、2.8 までのリリースを担当しました。
Michael Tiemann は、 GDB におけるGNU C++ サポートのほとんどを開発してくれました。 C++ のサポートについては、 Per Bothner からも重要な貢献がありました。 James Clark はGNU C++ のデマングラ (demangler) を開発してくれました。 C++ についての初期の仕事は Peter TerMaat によるものです (彼はまた、 リリース 3.0 までの一般的なアップデート作業の多くを担当してくれました)。
GDB 4は、 複数のオブジェクト・ファイル・フォーマットを調べるのに BFD サブルーチン・ライブラリを使用しています。 BFD は、 David V. Henkel-Wallace、 Rich Pixley、 Steve Chamberlain、 John Gilmore による共同プロジェクトです。
David Johnsonは、最初の COFF サポートを開発してくれました。 Pace Willisonは最初のカプセル化された COFF (encapsulated COFF) のサポートを開発してくれました。
Harris Computer Systems 社の Brent Benson は、 DWARF 2 のサポートに貢献してくれました。
Adam de Boorと Bradley Davis は ISI Optimum V のサポートに貢献してくれました。 Per Bpthner、引地信之、Alessandro Forinは、 MIPS のサポートに貢献してくれました。 Jean-Daniel Fekete は Sun 386i のサポートに貢献してくれました。 Chris Hanson は HP9000 サポートを改善してくれました。 引地信之と長谷井智之は、 Sony/News OS 3のサポートに貢献してくれました。 David Johnson は Encore Umax のサポートに貢献してくれました。 Jyrki Kuoppala は Altos 3068 のサポートに貢献してくれました。 Jeff Law は HP PAと SOM のサポートに貢献してくれました。 Keith Packard は NS32K のサポートに貢献してくれました。 Doug Rabson は Acorn Risc Machine のサポートに貢献してくれました。 Bob Rusk はHarris Nighthawk CX-UX のサポートに貢献してくれました。 Chris Smith は Convexのサポート (および、Fortran デバッグのサポート) に貢献してくれました。 Jonathan Stone は Pyramid のサポートに貢献してくれました。 Michael Tiemann は SPARCのサポートに貢献してくれました。 Tim Tucker は Gould NP1 と Gould Powernodeのサポートに貢献してくれました。 Pace Willson は Intel 386 のサポートに貢献してくれました。 Jay Vosburgh は Symmetry のサポートに貢献してくれました。
Rich Schaeferと Peter Shauer は SunOS 共用ライブラリのサポートを手伝ってくれました。
Jay FenlasonとRolald McGrathは、 GDBとGASがいくつかのマシン命令セットに関して共通の認識を持つようにしてくれました。
Patrick Duval、Ted Goldstein、Vikram Koka、Glenn Engel はリモート・デバッグ機能の開発を手伝ってくれました。 Intel社、Wind River Systems 社、AMD社、ARM社はそれぞれ、 i960、VxWorks、A29K UDI、RDI ターゲット用のリモート・デバッグ・モジュールを提供してくれました。
Brian Foxは、コマンドライン編集やコマンドライン・ヒストリを提供する readline ライブラリの開発者です。
SUNY Buffalo の Andrew Beers は言語切り替えコード と Modula-2 サポート を開発し、このマニュアルのプログラミング言語関連 (Languages) の章を提供してくれました。
Fred Fishは Unix System Vr4 サポートのほとんどを開発してくれました。 彼はまた、 C++のオーバロードされたシンボルを扱えるようコマンド補完機能を拡張してくれました。
Hitachi America, Ltd.社は、日立のマイクロ・プロセッサのサポートのスポンサーになってくれました。
Kung Hsu、Jeff Law、Rick Sladkey はハードウェア・ウォッチポイントのサポートを追加してくれました。
Michael Snyder はトレースポイントのサポートを追加してくれました。
Stu Grossmanは gdbserver を開発してくれました。
Jim Kingdon、Peter Schauer、Ian Taylor、Stu Grossman は GDB 全体に渡って、 ほとんど数えることができないほどのバグ・フィックスとコードの整理を行ってくれました。
Cygnus Solutions 社は、 1991 年以降、 GDB の保守作業と GDB の多くの開発作業のスポンサーになってくれています。
その気になれば、 このマニュアルを使ってGDBのすべてを学習することももちろん可能ですが、 GDBを使いはじめるには、 いくつかのコマンドを知っていれば十分です。 本章では、そのようなコマンドについて説明します。
GDBの出力情報との区別が容易につくように、 このサンプル・セッションでは、 ユーザの入力を input のように太字で表します。
汎用的なマクロ・プロセッサであるGNU m4
には、
かつて
(まだ正式なバージョンがリリースされる以前の話ですが)
次のような不具合がありました。
引用を表す文字列をデフォルトとは異なるものに変更すると、
あるマクロ定義の内部に入子状態になっている他のマクロ定義を取り出すために使われるコマンドが正しく動作しなくなることがある、
という不具合です。
以下では、
短いm4
セッションにおいて、
0000
に展開されるマクロfoo
を定義します。
そのあとで、
m4
の組み込みコマンドdefn
を使って、
マクロbar
に同一の定義を与えます。
ところが、
引用の開始文字列を<QUOTE>
に、
引用の終了文字列を<UNQUOTE>
にそれぞれ変更すると、
全く同一の手順で新しい同義語baz
を定義しようとすると、
失敗するのです。
$ cd gnu/m4 $ ./m4 define(foo,0000) foo 0000 define(bar,defn(`foo')) bar 0000 changequote(<QUOTE>,<UNQUOTE>) define(baz,defn(<QUOTE>foo<UNQUOTE>)) baz C-d m4: End of input: 0: fatal error: EOF in string
ここでGDBを使って、 何が起っているのか調べてみましょう。
$ gdb m4 GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.17, Copyright 1995 Free Software Foundation, Inc... (gdb)
GDBは、 他のシンボルを見つけるのに最低限必要なシンボル情報のみを読み込みます。 その結果、 最初のプロンプトが表示されるまでの時間が極めて短いのです。 ここで、 出力情報がこのマニュアルの紙幅に収まるようにするために、 GDBに対して表示幅を通常よりも狭くするよう指示を出してみましょう。
(gdb) set width 70
m4
の組み込みコマンドであるchangequote
がどのように動作するのかを調べてみる必要があります。
ソースを見ると、
関連するサブルーチンがm4_changequote
であることが分ります。
そこで、
GDBのbreak
コマンドでブレイクポイントを設定してみます。
(gdb) break m4_changequote Breakpoint 1 at 0x62f4: file builtin.c, line 879.
run
コマンドを使って、
GDBの管理下でm4
を走らせます。
m4_changequote
サブルーチンが呼ばれるまでの間は、
通常通りの動作をします。
(gdb) run Starting program: /work/Editorial/gdb/gnu/m4/m4 define(foo,0000) foo 0000
ブレイクポイントでプログラムを停止させるために、
changequote
を実行すると、
GDBはm4
の実行を停止し、
停止した箇所のコンテキスト情報を表示します。
changequote(<QUOTE>,<UNQUOTE>) Breakpoint 1, m4_changequote (argc=3, argv=0x33c70) at builtin.c:879 879 if (bad_argc(TOKEN_DATA_TEXT(argv[0]),argc,1,3))
次にn
(next
)コマンドを実行すると、
現在停止している関数の中で1行だけ処理が実行されます。
(gdb) n 882 set_quotes((argc >= 2) ? TOKEN_DATA_TEXT(argv[1])\ : nil,
set_quotes
というのは曰くありげなサブルーチンです。
next
コマンドの代りにs
(step
)コマンドを使うことで、
このサブルーチンの中に入ることができます。
step
コマンドは、
それがどのサブルーチンの中にあるかということにかかわりなく、
次の1行に移動します。
この場合、
次の1行はset_quotes
の中ですから、
そこへ移動することになります。
(gdb) s set_quotes (lq=0x34c78 "<QUOTE>", rq=0x34c88 "<UNQUOTE>") at input.c:530 530 if (lquote != def_lquote)
m4
が現在停止しているサブルーチン
(および、そのサブルーチンへの引数)
が表示されています。
これをスタック・フレーム表示と呼びます。
それは、
スタックの状態を要約した情報を表示しています。
backtrace
コマンド
(あるいは、
bt
と省略することもできます)
を使って、
現在スタック全体の中のどこにいるかを知ることもできます。
backtrace
コマンドは、
アクティブなサブルーチンのスタック・フレームを表示します。
(gdb) bt #0 set_quotes (lq=0x34c78 "<QUOTE>", rq=0x34c88 "<UNQUOTE>") at input.c:530 #1 0x6344 in m4_changequote (argc=3, argv=0x33c70) at builtin.c:882 #2 0x8174 in expand_macro (sym=0x33320) at macro.c:242 #3 0x7a88 in expand_token (obs=0x0, t=209696, td=0xf7fffa30) at macro.c:71 #4 0x79dc in expand_input () at macro.c:40 #5 0x2930 in main (argc=0, argv=0xf7fffb20) at m4.c:195
次に、2、3行先に進んで、
何が起こっているのかを見てみましょう。
最初の2回は、
`s'コマンドを使います。
続く2回は、
xstrdup
サブルーチンの中に入ってしまうのを防ぐために、
n
コマンドを使います。
(gdb) s 0x3b5c 532 if (rquote != def_rquote) (gdb) s 0x3b80 535 lquote = (lq == nil || *lq == '\0') ? \ def_lquote : xstrdup(lq); (gdb) n 536 rquote = (rq == nil || *rq == '\0') ? def_rquote\ : xstrdup(rq); (gdb) n 538 len_lquote = strlen(rquote);
最後に表示された行は、少し妙な感じがします。
2つの変数lquote
、
rquote
を調べて、
本当にそれが新たに指定された引用開始文字列、
引用終了文字列であるかどうか確認することができます。
値を調べるにはp
(print
)コマンドを使用します。
(gdb) p lquote $1 = 0x35d40 "<QUOTE>" (gdb) p rquote $2 = 0x35d50 "<UNQUOTE>"
lquote
とrquote
は確かに引用開始文字列、
引用終了文字列のようです。
コンテキストを調べるには、
l
(list
)コマンドを使って、
現在停止している行を中心にその前後10行を表示します。
(gdb) l 533 xfree(rquote); 534 535 lquote = (lq == nil || *lq == '\0') ? def_lquote\ : xstrdup (lq); 536 rquote = (rq == nil || *rq == '\0') ? def_rquote\ : xstrdup (rq); 537 538 len_lquote = strlen(rquote); 539 len_rquote = strlen(lquote); 540 } 541 542 void
len_lquote
とlen_rquote
に値を設定している行を実行させてから、
それらの値を調べてみましょう。
(gdb) n 539 len_rquote = strlen(lquote); (gdb) n 540 } (gdb) p len_lquote $3 = 9 (gdb) p len_rquote $4 = 7
len_lquote
とlen_rquote
が、
それぞれlquote
とrquote
の長さであるとすると、
ここに表示されている値は明らかに誤りです。
p
コマンドを使って、
正しい値を設定することができます。
p
コマンドは任意の式の値を表示することができますが、
ここでいう式とは、
サブルーチンの呼び出しや、
値の割り当てまでも含むのです。
(gdb) p len_lquote=strlen(lquote) $5 = 7 (gdb) p len_rquote=strlen(rquote) $6 = 9
m4
の組み込みコマンドdefn
に新しい引用文字列を使う際に発生した問題を修正するには、
これだけで十分でしょうか?
c
(continue
)コマンドを使えば、
m4
に処理を継続させて、
実際に問題を発生させていた例を実行することができます。
(gdb) c Continuing. define(baz,defn(<QUOTE>foo<UNQUOTE>)) baz 0000
今度はうまくいきました。
新たに設定された引用文字列は、
デフォルトの引用文字列と同じように機能しました。
問題の原因は、
プログラム内の2箇所のタイプ・ミスで、
長さの設定が正しく行われていないことにあったようです。
EOFを入力して、
m4
を終了させましょう。
C-d Program exited normally.
`Program exited normally.'というメッセージは、
GDBが出力したもので、
m4
の実行が終了したことを意味しています。
GDBの
quit
コマンドで、
GDBセッションを終了することができます。
(gdb) quit
本章では、 GDBの起動方法、 終了方法を説明します。 基本的には、
します。
gdb
というプログラムを実行することで、
GDBが起動されます。
ひとたび起動されると、
GDBは終了を指示されるまで、
端末からのコマンド入力を受け付けます。
あるいは、
最初からGDBのデバッグ環境を指定するために、
様々な引数やオプションを指定して
gdb
プログラムを実行することもできます。
ここで説明するコマンドライン・オプションは、 様々な状況に対応するために設計されたものです。 環境によっては、 ここで説明するオプションのいくつかは、 事実上使用できない場合もあります。
GDBを起動する際に最もよく使用される引数は、 デバッグされる実行プログラムの名前です。
gdb program
起動時に、 実行プログラム名とともに、 コア・ファイルの名前を指定することもできます。
gdb program core
あるいは、 既に実行中のプロセスをデバッグする場合には、 そのプロセス ID を第2引数に指定することもできます。
gdb program 1234
ここでは、
GDBはプロセス ID 1234
のプロセスにアタッチします
(ただし、
`1234'という名前のファイルが存在しないというのが条件です。
GDBはまずコア・ファイルの存在を確認します)。
このような第2引数の利用が可能であるためには、 かなり完成されたオペレーティング・システムが必要になります。 ボード・コンピュータに接続して、 リモート・デバッガとしてGDBを使用する場合には、 そもそも「プロセス」という概念がないかもしれませんし、 多くの場合、 コア・ダンプというものもないでしょう。
gdb
を起動すると、
GDBの無保証性を説明する文章が表示されますが、
-silent
オプションを指定することで、
これを表示しないようにすることもできます。
gdb -silent
コマンドライン・オプションを指定することで、 GDBの起動方法をさらに制御することができます。 GDB自身に、 使用可能なオプションを表示させることができます。
以下の
gdb -help
のようにgdbプログラムを実行することで、 使用可能なオプションがすべて、 その使用方法についての簡単な説明付きで表示されます (短縮して、 `gdb -h'という形で実行しても同じ結果が得られます)。
ユーザの指定したすべてのオプションと引数は、 順番に処理されます。 `-x'オプションが指定されている場合は特に、 順序の違いに意味がでてきます。
起動されたGDBは、 指定された引数のうちオプション以外のものは、 実行ファイル名およびコア・ファイル名 (あるいはプロセスID) であると解釈します。 これは、 `-se'オプションと`-c'オプションが指定されたのと同じことです (GDBは、 対応するオプション・フラグを持たない最初の引数を`-se'オプション付きと同等とみなし、 同じく対応するオプション・フラグを持たない第2の引数があれば、 これを`-c'オプション付きと同等とみなします)。
多くのオプションには、 完全形と短縮形があります。 以下の一覧では、 その両方を示します。 オプション名は、 他のオプションと区別がつけば、 最後まで記述しなくても、 GDBによって正しく認識されます (オプション名には`-'ではなく`--'を使うことも可能ですが、 ここでは一般的な慣例にしたがうこととします)。
-symbols file
-s file
-exec file
-e file
-se file
-core file
-c file
-c number
attach
コマンドを実行するのと同等です
(ただし、
numberで指定される名前のコア・ダンプ形式のファイルが存在する場合は、
そのファイルをコア・ダンプとして読み込みます)。
-command file
-x file
-directory directory
-d directory
-m
-mapped
mmap
システム・コールによるファイルのメモリへのマッピングが使用可能である場合、
このオプションを使うことで、
プログラムのシンボル情報を再利用可能なファイルとしてカレント・ディレクトリに書き出させることができます。
仮にデバッグ中のプログラム名が`/tmp/fred'であるとすると、
マップされたシンボル・ファイルは`./fred.syms'となります。
この後のGDBデバッグ・セッションは、
このファイルの存在を検出し、
そこから迅速にシンボル情報をマップします。
この場合、
実行プログラムからシンボル情報を読み込むことはありません。
`.syms'ファイルは、
GDBが実行されるホスト・マシンに固有のものです。
このファイルは、
内部のシンボル・テーブルのイメージをそのまま保存したものです。
これを、
複数のホスト・プラットフォーム上において、
共有することはできません。
-r
-readnow
-mapped
オプションと-readnow
オプションは、
完全なシンボル情報を含む`.syms'ファイルを構築するために、
通常一緒に指定されます
(詳しくは、ファイルを指定するコマンドを参照)。
GDBを様々なモードで実行することが可能です。 例えば、 batch モードや quietモードなどがあります。
-nx
-n
-quiet
-q
-batch
0
で終了します
(`-n'オプションによって禁止されていなければ、
初期化ファイル内に記述されているすべてのコマンドも実行されます)。
コマンド・ファイルに記述されたGDBコマンドの実行中にエラーが発生した場合には、
0
以外の終了コードで終了します。
batch モードはGDBをフィルターとして実行する場合に便利です。
例えば、
あるプログラムを別のコンピュータ上にダウンロードして実行する場合などです。
このような使い方の邪魔にならないよう、
Program exited normally.というメッセージは、 batch モードでは表示されません (通常このメッセージは、 GDBの管理下で実行中のプログラムが終了する時に、 必ず表示されます)。
-cd directory
-fullname
-f
-b bps
-tty device
quit
quit
コマンド
(省略形はq
)
を使用するか、
あるいは、
ファイルの終端文字
(通常はC-d)
を入力します。
expressionを指定しない場合、
GDBは正常終了します。
expressionが指定された場合、
expressionの評価結果をエラー・コードとして終了します。
割り込み (多くの場合C-c) はGDBを終了させません。 割り込みは通常、 実行中のGDBコマンドを終了させ、 GDBのコマンド・レベルに戻ります。 割り込み文字の入力はいつ行っても安全です。 というのは、 割り込みの発生が危険である間は、 GDBが割り込みの発生を抑止するからです。
アタッチされたプロセスやデバイスをコントロールするために
GDBを使用していた場合、
detach
コマンドでそれを解放することができます
(既に実行中のプロセスのデバッグを参照)。
デバッグ・セッションの途中でシェル・コマンドを実行する必要がある場合、
GDBを終了したり一時停止させたりする必要はありません。
shell
コマンドを使用することができます。
shell command string
SHELL
環境変数が設定されていれば、
その値が実行されるべきシェルを決定します。
SHELL
環境変数が設定されていなければ、
GDBは/bin/sh
を実行します。
開発環境ではしばしばmake
ユーティリティが必要とされます。
GDB内部でmake
ユーティリティを使用する場合は、
shell
コマンドを使用する必要はありません。
make make-args
make
プログラムを実行します。
これは、
`shell make make-args'を実行するのと同じことです。
GDBコマンドは、 コマンド名を最初の2、 3文字に短縮して使用することができます。 ただし、 短縮されたコマンド名があいまいであってはなりません。 さらに、 同じGDBコマンドを連続して使用する場合には、 RETキーを押すだけで十分です。 また、 TABキーを押すことで、 途中まで入力されたコマンド名を補完させることができます (複数の補完候補がある場合には、 その一覧を表示します)。
GDBコマンドは1行で入力されます。
1行の長さには上限がありません。
行は、
コマンド名で始まり、
コマンド名によって意味が決まる引数がそれに続きます。
例えば、
step
コマンドはstep
を実行する回数を引数に取ります。
例えば、
`step 5'のようになります。
step
コマンドは引数なしでも実行可能です。
コマンドによっては、
全く引数を受け付けないものもあります。
GDBコマンド名は省略可能です。
ただし、
省略された名前があいまいなものではあってはなりません。
省略形は、
それぞれのコマンドのドキュメント内に記載されています。
場合によっては、
あいまいな省略形も許されることがあります。
例えば、
s
は文字s
で始まるコマンドがほかにも存在するにもかかわらず、
step
コマンドの省略形として特別に定義されています。
ある省略形が使用可能か否かの判定は、
それをhelp
コマンドへの引数として使用することで可能です。
GDBへの入力として空行を与える
(RETキーのみを押す)
ことは、
1つ前に実行したコマンドを繰り返すということを意味します。
ただし、
いくつかのコマンド
(例えば、run
コマンド)は、
この方法で実行を繰り返すことはできません。
これらのコマンドは、
意図せざる再実行が問題を引き起す可能性があるので、
ユーザも繰り返し実行したくはないでしょう。
list
コマンドとx
コマンドは、
RETキーにより繰り返し実行すると、
新たに引数が生成されて実行されるので、
前回実行された時と全く同様の状態で繰り返し実行されるわけではありません。
こうすることで、
ソースコードの内容やメモリの内容を容易に調べることができます。
GDBは別の用途でもRETキーを使用します。
more
ユーティリティと同様の方法で、
長い出力を分割して表示する場合です
(画面サイズを参照)。
このような場合、
RETキーを余分に押してしまうことは往々にしてありえるので、
GDBはこのような表示方法を使用しているコマンドは、
キーによる繰り返し実行を行いません。
テキストの中に#記号があると、 そこから行末まではコメントになります。 コメントの部分は実行されません。 これは、 特にコマンド・ファイルの中で便利です (コマンド・ファイルを参照)。
途中まで入力されたコマンド名は、 それがあいまいでなければ、 GDBが残りの部分を補完してくれます。 また、 いつでも、 コマンド名の補完候補の一覧を表示してくれます。 この機能は、 GDBコマンド名、 GDBサブ・コマンド名、 ユーザ・プログラムのシンボル名に対して有効です。
GDBに単語の残りの部分を補完させたい場合には、 TABキーを押します。 補完候補が1つしか存在しない場合、 GDBは残りの部分を補完し、 ユーザがコマンドを (RETキーを押すことで) 完結させるのを待ちます。 例えば、 ユーザが以下のように入力したとしましょう。
(gdb) info bre TAB
GDBは`breakpoints'という単語の残りの部分を補完します。
何故なら、
info
コマンドのサブ・コマンドのうち、
`bre'で始まるのはこの単語のみだからです。
(gdb) info breakpoints
この時点で、
ユーザはRETキーを押してinfo breakpoints
コマンドを実行するか、
あるいは`breakpoints'コマンドが実行したいコマンドではなかった場合には、
バックスペース・キーを押して消去してから、
ほかの文字を入力することができます
(最初からinfo breakpoints
コマンドを実行するつもりであれば、
コマンド名補完機能ではなくコマンド名の省略形を利用して、
`info bre'と入力した後、
直ちにRETキーを押してもいいでしょう)。
TABキーが押された時に、 2つ以上の補完候補が存在する場合、 GDBは警告音を鳴らします。 さらにいくつか文字を入力してから補完を再度試みることも可能ですし、 単に続けてTABキーを押すことも可能です。 後者の場合、 GDBは補完候補の全一覧を表示します。 例えば、 `make_'で始まる名前を持つサブルーチンにブレイクポイントを設定したいような場合に、 b make_まで入力した後TABキーを入力したところ警告音が鳴ったとしましょう。 ここで続けてTABキーを入力すると、 プログラム内の`make_'で始まるすべてのサブルーチン名が表示されます。 例えば、 以下のように入力したとします。
(gdb) b make_ TAB
ここでGDBは警告音を鳴らします。 もう1度TABキーを入力すると、 以下のように表示されます。
make_a_section_from_file make_environ make_abs_section make_function_type make_blockvector make_pointer_type make_cleanup make_reference_type make_command make_symbol_completion_list (gdb) b make_
補完候補を表示した後、 ユーザが続きを入力できるよう、 GDBは途中まで入力された文字列 (ここでは`b make_') を再表示します。
もともと補完候補の一覧を表示したいのであれば、 TABキーを2回押す代わりにM-?を入力することもできます。 ここで、 M-?というのはMETA ?を意味します。 これを入力するには、 キーボード上にMETAシフト・キーとして指定されたキーがあれば、 それを押しながら?を入力します。 METAシフト・キーがない場合には、 ESCキーを押した後、 ?を入力します。
時には、
入力したい文字列が、
論理的には『単語』であっても、
GDBが通常単語の一部に含めない括弧のような文字を含む場合があります。
このような場合に単語の補完機能を使用するためには、
GDBコマンド内において、
そのような単語を'
(単一引用符)
で囲みます。
このようなことが必要になる可能性が最も高いのは、
C++ 関数名を入力する時でしょう。
これは、
C++が関数のオーバローディング
(引数の型の違いによって識別される同一名の関数の複数の定義)
をサポートしているからです。
例えば、
関数name
にブレイクポイントを設定する場合、
それがint
型のパラメータを取るname(int)
なのか、
それともfloat
型のパラメータを取るname(float)
なのかをはっきりさせる必要があります。
このような場合に単語の補完機能を使用するには、
単一引用符'
を関数名の前に入力します。
こうすることによって、
TABキーもしくはM-?キーが押されて単語補完が要求された時に、
補完候補の決定には通常よりも多くのことを検討する必要のあることがGDBに通知されます。
(gdb) b 'bubble( M-? bubble(double,double) bubble(int,int) (gdb) b 'bubble(
場合によっては、 名前の補完をするには、 引用符を使用する必要があるということをGDBが知らせてくれます。 このような場合、 ユーザが最初に引用符を入力していない場合、 GDBが (可能なかぎり補完を行いつつ) 引用符を挿入してくれます。
(gdb) b bub TAB GDBは入力された1行を以下のように変更し、警告音を鳴らします。 (gdb) b 'bubble(
一般的には、 オーバロードされたシンボルに対して補完が要求された場合に引数リストがまだ入力されていないと、 引用符が必要であると判断されます (そして実際に挿入します)。
help
コマンドを使うことで、
GDBコマンドに関するヘルプ情報をGDB自身に表示させることができます。
help
h
help
コマンド
(省略形はh
)
を引数なしで実行することで、
コマンドのクラス名の簡単な一覧を表示させることができます。
(gdb) help List of classes of commands: running -- Running the program stack -- Examining the stack data -- Examining data breakpoints -- Making program stop at certain points files -- Specifying and examining files status -- Status inquiries support -- Support facilities user-defined -- User-defined commands aliases -- Aliases of other commands obscure -- Obscure features Type "help" followed by a class name for a list of commands in that class. Type "help" followed by command name for full documentation. Command name abbreviations are allowed if unambiguous. (gdb)
help class
status
クラスを指定した場合の表示例を以下に示します。
(gdb) help status Status inquiries. List of commands: show -- Generic command for showing things set with "set" info -- Generic command for printing status Type "help" followed by command name for full documentation. Command name abbreviations are allowed if unambiguous. (gdb)
help command
help
の引数にコマンド名を指定することで、
そのコマンドの使用法に関する簡単な説明が表示されます。
complete args
complete args
コマンドにコマンド名の先頭の部分を指定すると、
コマンド名の補完候補の一覧を表示します。
argsには補完されるべきコマンド名の先頭の文字列を指定します。
例えば、
complete iは、以下のような結果を表示します。
info inspect ignoreこれは、 GNU Emacsでの使用を想定したものです。
help
コマンドに加えて、
GDBのinfo
コマンドおよびshow
コマンドを使用することで、
ユーザ・プログラムの状態やGDBの状態を問い合わせることができます。
どちらのコマンドも、
多くの観点からの問い合わせをサポートしています。
このマニュアルでは、
それぞれを適切と思われる箇所で紹介しています。
索引のinfo
とshow
の項には、
それぞれのサブ・コマンドが紹介されているページが示されています。
Indexを参照してください。
info
i
)
は、
ユーザ・プログラムの状態を表す情報を表示するものです。
例えば、
info args
によってユーザ・プログラムに与えられた引数を、
info registers
によって現在使用中のレジスタの一覧を、
info breakpoints
によってユーザが設定したブレイクポイントの一覧を、
それぞれ表示することができます。
help info
によって、
info
コマンドのサブ・コマンドの完全な一覧が表示されます。
set
set
コマンドによって、
ある式の評価結果を環境変数に割り当てることができます。
例えば、
GDBのプロンプト文字列を $ 記号に変更するには、
set prompt $
を実行します。
show
info
コマンドとは異なり、
show
コマンドはGDB自身の状態を表す情報を表示するものです。
show
コマンドで表示可能な状態はすべて、
対応するset
コマンドで変更可能です。
例えば、
数値の表示に使用する基数は
set radix
コマンドで管理できます。
現在どの基数が使用されているかを単に知るためには、
show radix
コマンドを使用します。
変更可能なすべてのパラメータとそれらの現在の値を表示するためには、
show
コマンドを引数なしで実行します。
または、
同様の目的でinfo set
コマンドを使用することもできます。
どちらのコマンドも、
同じ情報を出力します。
以下に、
対応するset
コマンドを持たないという意味で例外的である、
3つのshow
サブ・コマンドを示します。
show version
show copying
show warranty
プログラムをGDB配下で実行するには、 コンパイル時にデバッグ情報を生成する必要があります。 ユーザが選択した環境で、 必要に応じて引数を指定して、 GDBを起動することができます。 プログラムの入力元と出力先をリダイレクトすること、 既に実行中のプロセスをデバッグすること、 子プロセスを終了させることもできます。
プログラムを効率的にデバッグするためには、 そのプログラムのコンパイル時にデバッグ情報を生成する必要があります。 このデバッグ情報はオブジェクト・ファイルに格納されます。 この情報は、 個々の変数や関数の型、 実行形式コードのアドレスとソース・コード内の行番号との対応などを含みます。
デバッグ情報の生成を要求するには、 コンパイラの実行時に`-g'オプションを指定します。
多くの C コンパイラでは、 `-g'オプションと`-O'オプションを同時に指定することができません。 このようなコンパイラでは、 デバッグ情報付きの最適化された実行ファイルを生成することができません。
GNUの C コンパイラであるGCCは、 `-O'オプションの有無にかかわらず`-g'オプションが指定できます。 従って、 最適化されたコードをデバッグすることが可能です。 プログラムをコンパイルする時には、 常に`-g'オプションを指定することをお勧めします。 自分のプログラムは正しいと思うかもしれませんが、 自分の幸運を信じて疑わないというのは無意味なことです。
`-g -O'オプションでコンパイルされたプログラムをデバッグする時には、 オプティマイザがコードを再調整していることを忘れないでください。 デバッガは、 実際にあるコードの情報を表示します。 実行されるパスがソース・コードの記述とは異なっていても、 あまり驚かないでください。 これは極端な例ですが、 定義されているが実際には使われていない変数を、 GDBは認識しません。 何故なら、 コンパイラの最適化処理により、 そのような変数は削除されるからです。
命令スケジューリング機能を持つマシンなどでは、 `-g -O'でコンパイルされたプログラムは、 `-g'でコンパイルされたプログラムと同様には動作しない点がいくつかあります。 `-g -O'でコンパイルされたプログラムのデバッグで何かおかしな点があれば、 `-g'のみでコンパイルしてみてください。 これで問題が解決するようであれば、 (再現環境と一緒に) 障害として私たちに報告してください。
古いバージョンのGNU C コンパイラは、 デバッグ情報の生成のためのオプションの一つとして `-gg'をサポートしていました。 現在のGDBはこのオプションをサポートしていません。 お持ちのGNU C コンパイラにこのオプションがあるようであれば、 それは使わないでください。
run
r
run
コマンドを使用してください。
(VxWorks以外の環境では)
まずプログラム名を指定する必要があります。
これには、
GDBへの引数を使用する方法
(GDBの起動・終了を参照)
と、
file
またはexec-file
コマンドを使用する方法
(ファイルを指定するコマンドを参照)
とがあります。
プロセスをサポートする環境でプログラムを実行している場合、
run
コマンドは下位プロセスを生成し、
そのプロセスにプログラムを実行させます
(プロセスをサポートしない環境では、
run
コマンドはプログラムの先頭アドレスにジャンプします)。
プログラムの実行は、 上位プロセスから受け取る情報によって影響されます。 GDBはこの情報を指定する手段を提供しています。 これは、 ユーザ・プログラムが起動される前に実行されていなければなりません (ユーザ・プログラムの実行後にその情報を変更することも可能ですが、 その変更結果は次にプログラムを実行した時に初めて有効になります)。 この情報は、 4つに分類することができます。
run
コマンドへの引数として指定します。
ターゲット上でシェルが使用可能であれば、
引数を表現するのに通常用いる手法
(例えば、
ワイルドカード拡張や変数による代替など)
が使用できるよう、
シェルを経由して引数を渡します。
UNIX システムでは、
SHELL
環境変数によって、
使用されるシェルを管理することができます。
ユーザ・プログラムの引数を参照してください。
set environment
コマンドと
unset environment
コマンドを使用して、
ユーザ・プログラムの実行に影響する環境の一部を変更することができます。
ユーザ・プログラムの環境を参照してください。
cd
コマンドで設定可能です。
ユーザ・プログラムの作業ディレクトリを参照してください。
run
コマンドのコマンド・ライン上で、
標準入力、
標準出力をリダイレクトすることも可能です。
また、
tty
コマンドによって別のデバイスを割り当てることも可能です。
ユーザ・プログラムの入出力を参照してください。
注意: 入出力のリダイレクトは機能しますが、
デバッグ中のプログラムの出力を他のプログラムにパイプを使用して渡すことはできません。
このようなことをすると、
GDBは誤って別のプログラムのデバッグを開始してしまうことがあります。
run
コマンドを実行すると、
ユーザ・プログラムはすぐに実行を始めます。
プログラムを停止させる方法については、
停止と継続を参照してください。
プログラムが停止すると、
プログラム内の関数をprint
コマンドもしくはcall
コマンドを使用して呼び出すことができます。
データの検査を参照してください。
GDBが最後にシンボル情報を読み込んだ後、 シンボル・ファイルの修正タイムスタンプが変更されている場合、 GDBはシンボル・テーブルを破棄し再読み込みを行います。 この場合、 GDBはその時点におけるブレイクポイントの設定を保持しようと試みます。
ユーザ・プログラムへの引数は、
run
コマンドへの引数により指定可能です。
それはまずシェルに渡され、
ワイルドカードの展開やI/O のリダイレクトの後、
プログラムに渡されます。
SHELL
環境変数によって、
GDBの使用するシェルが指定されます。
SHELL
環境変数が定義されていないと、
GDBは/bin/sh
を使用します。
引数を指定せずに
run
コマンドを実行すると、
前回run
コマンドを実行した時の引数、
もしくは、
set args
コマンドで設定された引数が使用されます。
set args
set args
が引数なしで実行された場合、
run
コマンドはユーザ・プログラムを引数なしで実行します。
一度プログラムに引数を指定して実行すると、
次にプログラムを引数なしで実行する唯一の方法は、
run
コマンドを実行する前に
set args
コマンドを実行することです。
show args
環境とは、 環境変数とその値の集合のことです。 環境変数は、 慣例として、 ユーザ名、 ユーザのホーム・ディレクトリ、 端末タイプ、 実行プログラムのサーチ・パス等を記録します。 通常、 環境変数はシェル上で設定され、 ユーザの実行するすべてのプログラムによって継承されます。 デバッグ時には、 GDBを終了・再起動せずに環境を変更して、 ユーザ・プログラムを実行できると便利でしょう。
path directory
PATH
(実行ファイルのサーチ・パス)
の先頭に追加します。
これは、
GDBとユーザ・プログラムの両方に対して有効です。
`:'
(コロン)
もしくはスペースで区切られた複数のディレクトリを指定することもできます。
環境変数PATH
の中に既にdirectoryが含まれている場合には、
directoryは環境変数PATH
の先頭に移動されます。
これにより、
directoryはより早く検索されることになります。
文字列`$cwd'によって、
GDBがパスを検索する時点における作業ディレクトリを参照することができます。
`.'
(ピリオド)
を使用すると、
path
コマンドを実行したディレクトリを参照することになります。
directory引数に`.'
(ピリオド)
が含まれていると、
GDBはまずそれを
(カレント・ディレクトリに)
置き換えてから、
サーチ・パスに追加します。
show paths
PATH
の値)を表示します。
show environment [varname]
environment
はenv
に省略可能です。
set environment varname [=] value
set env USER = foo
unset environment varname
unset environment
は、
環境変数の値を空文字列に設定するのではなく、
環境変数そのものを環境から削除します。
注意: GDBは、
環境変数SHELL
により指定されるシェル
(環境変数SHELL
が設定されていない場合には/bin/sh
)
を使用してプログラムを実行します。
SHELL
環境変数の指定するシェルが初期化ファイルを実行するものである場合
(例えば、
C-shellの`.cshrc'、
BASH の`.bashrc')、
初期化ファイルの中で設定された環境変数はユーザ・プログラムに影響を与えます。
環境変数の設定は、
`.login'や`.profile'のように、
ユーザがシステム内に入る時に実行されるファイルで行うのが良いかもしれません。
run
コマンドで実行されるユーザ・プログラムは、
実行時のGDBの作業ディレクトリを継承します。
GDBの作業ディレクトリは、
もともと親プロセス
(通常はシェル)
から継承したものですが、
cd
コマンドによってGDBの中から新しい作業ディレクトリを指定することができます。
GDBの作業ディレクトリは、 GDBが操作するファイルを指定するコマンドに対して、 デフォルト・ディレクトリとして機能します。 ファイルを指定するコマンドを参照してください。
cd directory
pwd
GDB配下で実行されるプログラムは、 デフォルトでは、 GDBと同一の端末に対して入出力を行います。 GDBは、 ユーザとのやりとりのために、 端末モードをGDB用に変更します。 この時、 ユーザ・プログラムが使用していた端末モードは記録され、 ユーザ・プログラムを継続実行すると、 そのモードに戻ります。
info terminal
run
コマンドにおいてシェルのリダイレクト機能を使用して、
ユーザ・プログラムの入出力をリダイレクトすることが可能です。
例えば
run > outfile
はユーザ・プログラムの実行を開始し、 その出力をファイル`outfile'に書き込みます。
ユーザ・プログラムがどこに入出力を行うかを指定する別の方法に、
tty
コマンドがあります。
このコマンドはファイル名を引数として取り、
そのファイルを後に実行されるrun
コマンドのデフォルトの入出力先とします。
このコマンドはまた、
後のrun
コマンドにより生成される子プロセスを管理する端末を変更します。
例えば、
tty /dev/ttyb
は、
それ以降に実行されるrun
コマンドにより起動されるプロセスのデフォルトの入出力先および管理端末を`/dev/ttyb'端末とします。
run
コマンド実行時に明示的にリダイレクト先を指定することで、
tty
コマンドで指定された入出力装置を変更することができますが、
管理端末の設定は変更できません。
tty
コマンドを使用しても、
また、
run
コマンドで入力をリダイレクトしても、
ユーザ・プログラムの入力元のみが変更されます。
これらのコマンドを実行しても、
GDBの入力元は、ユーザの使用している端末のままです。
attach process-id
info files
コマンドで現在デバッグ対象となっているプログラムの情報が表示されます)。
このコマンドは、
プロセスID を引数に取ります。
UNIX プロセスのプロセス ID を知るのに通常使用する方法は、
ps
ユーティリティもしくはシェル・コマンドの`jobs -l'の実行です。
attach
コマンドを実行後RETキーを押しても、
コマンドは再実行されません。
attach
コマンドを使用するには、
プロセスをサポートする環境でユーザ・プログラムを実行する必要があります。
例えば、
オペレーティング・システムの存在しないボード・コンピュータのような環境で動作するプログラムに対して、
attach
コマンドを使うことはできません。
さらに、
ユーザはプロセスに対してシグナルを送信する権利を持っている必要があります。
attach
コマンドを使用するには、
まずfile
コマンドによりプロセスの実行ファイルを指定し、
そのシンボル・テーブルをロードする必要があります。
ファイルを指定するコマンドを参照してください。
指定されたプロセスをデバッグする準備が整った後にGDBが最初にすることは、
そのプロセスを停止することです。
run
コマンドを使用してプロセスを起動した時に通常使用可能なすべてのGDBコマンドを使用して、
アタッチされたプロセスの状態を調べたり変更したりすることができます。
ブレイクポイントの設定、
ステップ実行、
継続実行、
内部情報の変更が可能です。
プロセスの実行を継続したいのであれば、
GDBがプロセスにアタッチした後continue
コマンドを使用します。
detach
detach
コマンドを使用してそのプロセスをGDBの管理から解放することができます。
プロセスからディタッチしても、
そのプロセスは実行を継続します。
detach
コマンド実行後は、
ディタッチされたプロセスと
GDBは互いに完全に依存関係がなくなり、
attach
コマンドによる別のプロセスへのアタッチや
run
コマンドによる別のプロセスの起動が可能になります。
detach
コマンドを実行後RETキーを押しても、
detach
コマンドは再実行されません。
プロセスがアタッチされている状態で、
GDBを終了したりrun
コマンドを使用したりすると、
アタッチされたプロセスを終了させてしまいます。
デフォルトの状態では、
GDBはプロセスを終了させて新しい処理を実行するかどうかをユーザに確認します。
この確認処理を行うか否かは、
set confirm
コマンドで設定可能です
(オプションの警告およびメッセージを参照)。
kill
このコマンドは、 実行中のプロセスではなく、 コア・ダンプをデバッグしたい時に便利です。 GDBは、 ユーザ・プログラムの実行中は、 コア・ダンプ・ファイルを無視します。
いくつかのオペレーティング・システム上では、
GDBの管理下でブレイクポイントを設定されている状態のプログラムを、
GDBの外で実行することができません。
このような場合、
kill
コマンドを使用することで、デバッガの外でのプログラムの実行が可能になります。
kill
コマンドは、
プログラムを再コンパイル、
再リンクしたい場合にも便利です。
というのは、
多くのシステムでは、
プロセスとして実行中の実行ファイルを更新することはできないからです。
次にrun
コマンドを実行した時には、
GDBはファイルが変更されていることを認識し、
シンボル・テーブルを再度読み込みます
(この際、その時点でのブレイクポイントの設定を維持しようと試みます)。
いくつかのオペレーティング・システムは、
`/proc'と呼ばれる便利な機能を提供しています。
これは、
ファイル・システム関連の関数を使用して、
実行中プロセスのイメージを調べるのに使用できます。
もし
GDBがこの機能を持つオペレーティング・システム用に設定されていれば、
info proc
コマンドを使用することで、
ユーザ・プログラムを実行しているプロセスに関するいくつかの情報を知ることができます。
info proc
は、
procfs
をサポートする SVR4 システム上でのみ機能します。
info proc
info proc mappings
info proc times
info proc id
info proc status
info proc all
オペレーティング・システムによっては、 1つのプログラムが複数のスレッドを実行することができます。 スレッドの意味するところはオペレーティング・システムによって異なりますが、 一般的に言って、 1つのアドレス空間を共有するという点を除けば、 プログラム内のマルチスレッドは、 マルチプロセスと類似しています (アドレス空間の共有とは、 複数のスレッドが同一の変数の値を参照したり変更したりすることが可能であるということです)。 その一方で、 個々のスレッドは自分用のレジスタ、 実行スタック、 そして恐らくはプライベート・メモリを持ちます。
GDBはマルチスレッド・プログラムのデバッグ用に以下のような便利な機能を提供しています。
注意: これらの機能は、 スレッドをサポートするオペレーティング・システム用に設定されたすべてのGDBで使用可能なわけではありません。 GDBがスレッドをサポートしていない環境では、 これらのコマンドは無効です。 例えば、 スレッドをサポートしていないシステム上で GDBの`info threads'コマンドを実行しても何も表示されませんし、
thread
コマンドの実行は常に拒絶されます。(gdb) info threads (gdb) thread 1 Thread ID 1 not known. Use the "info threads" command to see the IDs of currently known threads.
GDBのスレッド・デバッグ機能により、 ユーザ・プログラム実行中にすべてのスレッドを観察することができます。 ただし、 GDBに制御権のある状態では、 特定の1つのスレッドのみがデバッグの対象となります。 このスレッドは、 カレント・スレッドと呼ばれます。 デバッグ用のコマンドは、 カレント・スレッドの立場から見たプログラムの情報を表示します。
ユーザ・プログラム内部において新しいスレッドの存在を検出すると、 `[New systag]'という形式で、 ターゲット・システム上におけるこのスレッドの ID を表示します。 ここでsystagとはスレッドの ID で、 その形式はシステムによって異なります。 例えば、 LynxOS上では、 GDBが新しいスレッドを検出すると、
[New process 35 thread 27]
の様に表示されます。 一方、 SGI のシステム上では、 systagは単に`process 368'の様な形式で、 これ以外の情報はありません。
デバッグのために、 GDBはユーザ・プログラム内の個々のスレッドに、 整数値のスレッド番号を独自に割り当てます。
info threads
(gdb) info threads 3 process 35 thread 27 0x34e5 in sigpause () 2 process 35 thread 23 0x34e5 in sigpause () * 1 process 35 thread 13 main (argc=1, argv=0x7ffffff8) at threadtest.c:68
thread threadno
(gdb) thread 2 [Switching to process 35 thread 23] 0x34e5 in sigpause ()`[New ...]'メッセージと同様、 `Switching to'のあとに表示される情報の形式は、 そのシステムにおけるスレッドの識別方法に依存します。
thread apply [threadno] [all] args
thread apply
コマンドにより、
1つのコマンドを1つ以上のスレッドに対して実行することができます。
実行対象となるスレッドのスレッド番号を引数
threadnoに指定します。
threadnoは、
`info threads'コマンドの出力の最初のフィールドに表示されるGDB内部のスレッド番号です。
すべてのスレッドに対してコマンドを実行するには、
thread apply all
argsコマンドを使用してください。
GDBがユーザ・プログラムを停止させる時、 その理由がブレイクポイントであれシグナルの受信であれ、 ブレイクポイントの設定されたスレッド、 もしくは、 シグナルを受信したスレッドが自動的に選択されます。 GDBは、 `[Switching to systag]'という形式のメッセージでそのスレッドを示し、 コンテキスト切り替えの発生に注意を促します。
複数スレッドを持つプログラムの停止時、起動時の GDB の動作の詳細については、 マルチスレッド・プログラムの停止と起動を参照してください。
また、 複数スレッドを持つプログラム内におけるウォッチポイントについては、 ウォッチポイントの設定を参照してください。
fork
関数を使用して新たにプロセスを生成するプログラムのデバッグに対する特別な機能をGDBは提供していません。
プログラムが fork を実行する時、
GDB
は引き続き親プロセスのデバッグを継続し、
子プロセスは妨げられることなく実行を続けます。
子プロセスが実行するコードにブレイクポイントを設定してあると、
子プロセスはSIGTRAP
シグナルを受信し、
(そのシグナルをキャッチする処理がなければ)
子プロセスは終了してしまいます。
しかし、
子プロセスをデバッグしたい場合には、
それほど困難ではない回避策があります。
forkを実行後に子プロセスが実行するコードの中にsleep
関数の呼び出しを加えてください。
GDBに子プロセスのデバッグをさせる理由がない時に遅延が発生することのないように、
特定の環境変数が設定されている時、
あるいは、
特定のファイルが存在する時だけsleep
関数を呼ぶようにするとよいでしょう。
子プロセスがsleep
を呼んでいる間に、
ps
ユーティリティを使用して子プロセスのプロセス ID を獲得してください。
次に、
GDBに対して
(親プロセスもデバッグしたいのであれば、
新たにGDBを起動して、
そのGDBに対して)、
子プロセスにアタッチするよう指示してください
(既に実行中のプロセスのデバッグを参照してください)。
これ以降、
通常プロセスにアタッチした場合とまったく同様に、
子プロセスのデバッグが可能です。
デバッガを使用する主要な目的は、 プログラムが終了してしまう前に停止させたり、 問題のあるプログラムを調査して何が悪いのかを調べたりすることにあります。
GDB内部においてプログラムが停止する理由はいくつかあります。
例えば、
シグナルの受信、
ブレイクポイントへの到達、
step
コマンド実行後の新しい行への到達等です。
プログラムが停止すると、
変数の値の調査や設定、
新しいブレイクポイントの設定、
既存のブレイクポイントの削除などを行った後、
プログラムの実行を継続することができます。
通常、
GDBが表示するメッセージは、
ユーザ・プログラムの状態について多くの情報を提供してくれます。
ユーザはいつでも明示的にこれらの情報を要求することができます。
info program
ブレイクポイントによって、
プログラム内のある特定の箇所が実行される時に、
プログラムを停止することができます。
個々のブレイクポイントについて、
そのブレイクポイントにおいてプログラムを停止させるために満足されなければならない、
より詳細な条件を設定することができます。
ブレイクポイントの設定は、
一連のbreak
コマンドのいずれかによって行います
(ブレイクポイントの設定を参照)。
行番号、
関数名、
プログラム内のアドレスを指定することで、
プログラムのどこで停止するかを指定することができます。
例外処理機能を持つ言語
(例えば、
GNU C++)
では、
例外の発生箇所にブレイクポイントを設定することもできます
(ブレイクポイントと例外を参照)。
SunOS 4.x、 SVR4、 Alpha OSF/1 上では、 実行開始前に共用ライブラリ内にブレイクポイントを設定することもできます。
ウォッチポイントは、 ある式の値が変化した時にユーザ・プログラムを停止させる、 特別なブレイクポイントです。 ウォッチポイントは、 ほかのブレイクポイントと同じように管理することができますが、 ウォッチポイントの設定だけは別のコマンドで行います (ウォッチポイントの設定を参照)。 ブレイクポイントおよびウォッチポイントの有効化、 無効化、 削除に使用するコマンドは同一です。
ブレイクポイントでGDBが停止した時には常に、 自動的にユーザ・プログラム内のある値を表示させるようにすることができます。 自動表示を参照してください。
ユーザが新規に作成した個々のブレイクポイントおよびウォッチポイントに、 GDBは番号を割り当てます。 この番号は1から始まる連続する整数値です。 ブレイクポイントの様々な側面を制御するコマンドの多くにおいて、 ユーザは変更を加えたいブレイクポイントを指定するのにこの番号を指定します。 個々のブレイクポイントを有効化、 無効化することができます。 無効化されたブレイクポイントは、 再度有効化されるまで、 ユーザ・プログラムの実行に影響を与えません。
ブレイクポイントはbreak
コマンド
(省略形はb
)
によって設定されます。
デバッガのコンビニエンス変数`$bpnum'に、
ユーザが最後に設定したブレイクポイントの番号が記録されます。
コンビニエンス変数の使用方法については、
コンビニエンス変数を参照してください。
ブレイクポイントの設定箇所を指定する方法はいくつかあります。
break function
break +offset
break -offset
break linenum
break filename:linenum
break filename:function
break *address
break
break
コマンドは選択されたスタック・フレーム内において次に実行される命令にブレイクポイントを設定します
(スタックの検査を参照)。
最も内側のスタック・フレーム以外のフレームが選択されていると、
このブレイクポイントは、制御が現在のフレームに戻ってきた時点で、
ユーザ・プログラムを停止させます。
これが持つ効果は、
選択されたフレーム内部のフレームにおいて
finish
コマンドを実行するのと似ています。
ただし、
1つ異なるのは、
finish
コマンドがアクティブなブレイクポイントを残さないという点です。
最も内側のスタック・フレームにおいて引数なしで
break
コマンドを実行した場合、
現在停止している箇所に次に到達した時に、
GDBはユーザ・プログラムを停止させます。
これは、
ループの内部では便利でしょう。
GDBは通常、
実行を再開したときに、
最低でも1命令が実行されるまでの間は、
ブレイクポイントの存在を無視します。
そうでなければ、
ブレイクポイントで停止した後、
そのブレイクポイントを無効にしない限り、
先へ進めないことになってしまいます。
この規則は、
ユーザ・プログラムが停止したときに、
そのブレイクポイントが存在したか否かにかかわらず、
適用されます。
break ... if cond
tbreak args
break
コマンドと同様であり、
ブレイクポイントも同様に設定されますが、
tbreak
により設定されたブレイクポイントは、
プログラムが最初にそこで停止した後に自動的に削除されます。
ブレイクポイントの無効化を参照してください。
hbreak args
break
コマンドと同様であり、
ブレイクポイントも同様に設定されますが、
hbreak
により設定されるブレイクポイントはハードウェアによるサポートを必要とします。
ターゲット・ハードウェアによっては、
このような機能を持たないものもあるでしょう。
これが目的とするところは、
EPROM/ROMコードのデバッグであり、
ユーザはある命令にブレイクポイントを設定するのに、
その命令を変更する必要がありません。
これは、
SPARClite DSUの提供するトラップ発生機能と一緒に使用することができます。
DSU は、
デバッグ・レジスタに割り当てられた
データ・アドレスあるいは命令アドレス
をプログラムがアクセスすると、
トラップを発生させます。
ハードウェアの提供するブレイクポイント・レジスタはデータ・ブレイクポイントを2つまでしか取れないので、
このコマンドが3つ以上使用しようとすると、
GDBはそれを拒絶します。
このような場合、
不要になったハードウェア・ブレイクポイントを削除もしくは無効化してから、
新しいハードウェア・ブレイクポイントを設定してください。
ブレイクポイントの成立条件を参照してください。
thbreak args
hbreak
コマンドと同様であり、
ブレイクポイントも同様に設定されます。
しかし、
tbreak
コマンドの場合と同様、
最初にプログラムがそこで停止した後に、
このブレイクポイントは自動的に削除されます。
また、
hbreak
コマンドの場合と同様、
このブレイクポイントはハードウェアの持つ機能を利用するものであり、
ターゲット・ハードウェアによっては、
そのような機能がないこともあるでしょう。
ブレイクポイントの無効化を参照してください、
および、
ブレイクポイントの成立条件を参照してください。
rbreak regex
break
コマンドで設定されたブレイクポイントと同様に扱われます。
ほかのすべてのブレイクポイントと同様の方法で、
削除、
無効化、
条件の設定が可能です。
C++プログラムをデバッグする際に、
任意の特別なクラスのメンバではないオーバロードされた関数にブレイクポイントを設定するのに、
rbreak
コマンドは便利です。
info breakpoints [n]
info break [n]
info watchpoints [n]
info break
コマンドは、
そのブレイクポイントに関する情報の次の行に、
その条件を表示します。
ブレイクポイント・コマンドがあれば、
続いてそれが表示されます。
info break
コマンドに引数としてブレイクポイント番号nが指定されると、
その番号に対応するブレイクポイントだけが表示されます。
コンビニエンス変数
$_
およびx
コマンドのデフォルトの参照アドレスには、
一覧の中で一番最後に表示されたブレイクポイントのアドレスが設定されます
(メモリの調査を参照)。
info break
コマンドは、
ブレイクポイントに到達した回数も表示します。
これは、
ignore
コマンドと組み合わせると便利です。
まずignore
コマンドでブレイクポイントへの到達をかなりの回数無視するよう設定します。
プログラムを実行し、
info break
コマンドの出力結果から何回ブレイクポイントに到達したかを調べます。
再度プログラムを実行し、
今度は前回実行時に到達した回数より1だけ少ない回数だけ無視するように設定します。
こうすることで、
前回実行時にそのブレイクポイントに最後に到達した時と同じ状態でプログラムを停止させることが簡単にできます。
GDBでは、 ユーザ・プログラム内の同一箇所に何度でもブレイクポイントを設定することができます。 これは、 くだらないことでも、 無意味なことでもありません。 設定されるブレイクポイントが条件付きのものである場合、 これはむしろ有用です (ブレイクポイントの成立条件を参照)。
GDB自身が、
特別な目的でユーザ・プログラム内部にブレイクポイントを設定することがあります。
例えば、
(Cプログラムにおける)
longjmp
を適切に処理するためなどです。
これらの内部的なブレイクポイントには-1
から始まる負の番号が割り当てられます。
`info breakpoints'コマンドは、
これらのブレイクポイントを表示しません。
これらのブレイクポイントは、 GDBの保守コマンド`maint info breakpoints'で表示することができます。
maint info breakpoints
breakpoint
watchpoint
longjmp
longjmp
が呼び出された時に正しくステップ処理ができるよう内部的に設定されたブレイクポイント
longjmp resume
longjmp
のターゲットとなる箇所に内部的に設定されたブレイクポイント
until
until
コマンドで一時的に使用される内部的なブレイクポイント
finish
finish
コマンドで一時的に使用される内部的なブレイクポイント
ウォッチポイントを設定することで、 ある式の値が変化した時に、 その値の変更がプログラムのどの部分で起こるかを予め知ることなく、 プログラムの実行を停止させることができます。
現在のところ、 ウォッチポイントは他のブレイクポイントと比較して2倍以上の時間がかかります。 それでも、 プログラムのどの部分が問題を発生させたのかまったく手掛りのない誤りを検出できるのは、 十分価値のあることです。
watch expr
watch
コマンドを支援してくれます。
しかし、
ハードウェアのブレイクポイント・レジスタはデータに対するウォッチポイントを2つまでしか持てませんし、
2つのウォッチポイントは同一タイプでなければなりません。
例えば、
watch
コマンドによる2つのウォッチポイントの設定、
rwatch
コマンドによる2つのウォッチポイントの設定、
awatch
コマンドによる2つのウオッチポイントの設定はいずれも可能です。
しかし、
2つのウォッチポイントを異なるコマンドで設定することはできません。
2つのタイプのウォッチポイントを混在させようとすると、
GDBにより拒絶されます。
新たにウォッチポイントを設定する際には、
不要なウォッチポイントを削除もしくは無効化してください。
rwatch expr
rwatch
コマンドで設定されていなければなりません。
awatch expr
awatch
コマンドで設定されていなければなりません。
info watchpoints
info break
と同様のコマンドです。
注意: マルチスレッド・プログラムでは、 ウォッチポイントの有用性は限定されます。 現在のウォッチポイントの実装では、 GDBは単一スレッド内部でしか式の値を監視することができません。 式の値が、 カレント・スレッドの処理によってのみ変更されることが確実であれば (そして、 他のスレッドがカレントにならないことが確実であれば)、 ウォッチポイントを通常どおり使用することができます。 しかし、 カレント・スレッド以外のスレッドが式の値を変更させると、 GDBはその変更に気がつかないかもしれません。
GNU C++などの言語は、 例外処理を実装しています。 GDBを使用することで、 どのような原因でユーザ・プログラムが例外を発生させたのかを調べたり、 ある一時点においてユーザ・プログラムが処理することのできる例外の一覧を表示させたりすることができます。
catch exceptions
catch
コマンドを使用することで、
アクティブな例外ハンドラにブレイクポイントを設定することができます。
exceptionsには、
キャッチすべき例外の名前の一覧を指定します。
info catch
コマンドにより、
アクティブな例外ハンドラの一覧を表示することができます。
フレームに関する情報を参照してください。
現在、 GDBの例外処理にはいくつかの制限があります。
例外処理をデバッグするのに、
catch
コマンドが最適な手段ではないような場合もあります。
どこで例外が発生したのかを正確に知りたい場合、
例外ハンドラが呼び出される前にプログラムを停止させた方が良いでしょう。
なぜなら、
スタック・ポインタの調整が行われる前のスタックの状態を見ることができるからです。
例外ハンドラの内部にブレイクポイントを設定してしまうと、
どこで例外が発生したのかを調べるのは簡単ではないでしょう。
例外ハンドラが呼び出される直前で停止させるには、
実装に関する知識が若干必要になります。
GNU C++の場合、
以下のような ANSI C インターフェイスを持つ__raise_exception
というライブラリ関数を呼び出すことで例外を発生させます。
/* addrは例外識別子が格納される領域です idは例外識別子です */ void __raise_exception (void **addr, void *id);
スタック・ポインタの調整が行われる前に、
すべての例外をデバッガにキャッチさせるには、
__raise_exception
にブレイクポイントを設定します
(ブレイクポイント、ウォッチポイント、例外を参照)。
idの値に依存する条件付きのブレイクポイント (ブレイクポイントの成立条件を参照) を使用することで、 特定の例外が発生した時にだけユーザ・プログラムを停止させることができます。 複数の条件付きブレイクポイントを設定することで、 複数の例外の中のどれかが発生した時にユーザ・プログラムを停止させることができます。
ブレイクポイントやウォッチポイントが一度プログラムを停止させた後、 再度同じブレイクポイント、 ウォッチポイントでプログラムを停止させたくない場合、 それらを取り除くことがしばしば必要になります。 これが、 ブレイクポイントの削除と呼ばれるものです。 削除されたブレイクポイントはもはや存在せず、 それが存在したという記録も残りません。
clear
コマンドを使用する場合、
ブレイクポイントを、
それがプログラム内部のどこに存在するかを指定することによって、
削除します。
delete
コマンドの場合は、
ブレイクポイント番号を指定することで、
個々のブレイクポイント、
ウォッチポイントを削除することができます。
ブレイクポイントで停止した後、 先へ進むために、 そのブレイクポイントを削除する必要はありません。 ユーザが実行アドレスを変更することなく実行を継続する場合、 GDBは最初に実行される命令に設定されているブレイクポイントを自動的に無視します。
clear
clear function
clear filename:function
clear linenum
clear filename:linenum
delete [breakpoints] [bnums...]
set confirm off
コマンドが事前に実行されていない場合、
GDBは、
削除してもよいかどうか確認を求めてきます)。
このコマンドの省略形は
d
です。
ブレイクポイントやウォッチポイントを削除するのではなく、 無効化したい場合もあるでしょう。 これは、 ブレイクポイントを、 それがあたかも削除されたかのように機能しなくしてしまいますが、 後に再度有効にすることができるよう、 そのブレイクポイントに関する情報を記憶します。
ブレイクポイントおよびウォッチポイントは、
enable
とdisable
コマンドによって有効化、
無効化します。
これらのコマンドには、
引数として1つ以上のブレイクポイント番号を指定することも可能です。
指定すべき番号が分らない場合は、
info break
コマンドもしくはinfo watch
コマンドによってブレイクポイント、
ウォッチポイントの一覧を表示してください。
ブレイクポイント、 ウォッチポイントは、 有効/無効という観点からは4つの異なる状態を持つことができます。
break
コマンドで設定されたブレイクポイントの初期状態はこの状態です。
tbreak
コマンドで設定されたブレイクポイントの初期状態はこの状態です。
以下のコマンドを使用することで、 ブレイクポイントおよびウォッチポイントの有効化、 無効化が可能です。
disable [breakpoints] [bnums...]
disable
コマンドは
dis
と省略することができます。
enable [breakpoints] [bnums...]
enable [breakpoints] once bnums...
enable [breakpoints] delete bnums...
tbreak
コマンド
(ブレイクポイントの設定を参照)
で設定されたブレイクポイントを除き、
ユーザによって設定されたブレイクポイントの初期状態は有効状態です。
その後、
ユーザが上記のコマンドのいずれかを使用した場合に限り、
無効化されたり有効化されたりします
(until
コマンドは、
それ自身でブレイクポイントを設定し削除することができますが、
ユーザの設定した他のブレイクポイントの状態は変更しません。
継続実行とステップ実行を参照してください)。
最も単純なブレイクポイントは、 指定された箇所にプログラムが到達する度に、 プログラムの実行を停止させます。 ブレイクポイントに対して条件を指定することも可能です。 ここで、 「条件」とは、 プログラムが記述された言語において真偽値を表す式のことです (式を参照)。 条件付きのブレイクポイントにプログラムが到達する度に、 その式が評価されます。 そして、 その結果が真であった場合だけ、プログラムは停止します。
これは、 プログラムの正当性を検査するために診断式を使用するのとは逆になります。 この場合は、 診断式が成立しない時、 すなわち条件が偽である場合に、 ユーザはプログラムを停止させます。 C言語では、 assertという診断式をテストするためには、 しかるべきブレイクポイントに`! assert'という条件を設定します。
ウォッチポイントに対して条件を設定することもできます。 もともとウォッチポイントは、 ある式の値を検査するものなのですから、 これは必要ないかもしれません。 しかし、 ある変数の新しい値がある特定の値に等しいか否かを検査するのは条件式に任せて、 ウォッチポイントの対象そのものは単にその変数の名前にするという設定の方が簡単でしょう。
ブレイクポイントの成立条件に副作用を持たせたり、 場合によってはプログラム内部の関数を呼び出させたりすることもできます。 プログラムの進行状況をログに取る関数を呼び出したり、 特別なデータ構造をフォーマットして表示するユーザ定義の関数を使用したい場合などに便利です。 この効果は、 同一アドレスに有効なブレイクポイントが別に設定されていない限り、 完全に予測可能です (別のブレイクポイントが設定されていると、 GDBはこのブレイクポイントを先に検出し、 他のブレイクポイントで設定した条件式をチェックすることなくプログラムを停止させてしまうかもしれません)。 ただし、 あるブレイクポイントに到達した時に、 副作用を持つ処理を実行させるためには、 ブレイクポイント・コマンドの方がより便利であり、 より柔軟でしょう (ブレイクポイント・コマンド・リストを参照)。
ブレイクポイントの成立条件は、
ブレイクポイントを設定する際にbreak
コマンドの引数に`if'を使用することで、設定できます。
ブレイクポイントの設定を参照してください。
ブレイクポイントの成立条件は、
condition
コマンドによっていつでも変更できます。
watch
コマンドはif
キーワードを認識しません。
ウォッチポイントに対して条件を追加設定する唯一の方法は、
condition
コマンドを使うことです。
condition bnum expression
condition
コマンドを使用すると、
GDBは直ちにexpressionの構文の正当性、
および、
expressionの中で使用されるシンボル参照の、
ブレイクポイントのコンテキストにおける有効性をチェックします。
しかし、
GDBはcondition
コマンドが実行される時に
expressionの値を実際に評価する訳ではありません。
式を参照してください。
condition bnum
ブレイクポイント成立条件の特別なものに、 ブレイクポイントに到達した回数がある数に達した時にプログラムを停止させるというものがあります。 これは大変便利なので、 それを実現するための特別な方法が提供されています。 それは、 ブレイクポイントの通過カウント (ignore count) を使用する方法です。 すべてのブレイクポイントは、 通過カウントと呼ばれる整数値を持っています。 ほとんどの場合、 この通過カウントの値はゼロであり、 何ら影響力を持ちません。 しかし、 通過カウントとして正の値を持つブレイクポイントに到達すると、 ユーザ・プログラムはそこで停止せず、 単に通過カウントの値を1減少させて処理を継続します。 したがって、 通過カウントがnであると、 ユーザ・プログラムがそのブレイクポイントに到達した回数がn以下の間は、 そのブレイクポイントにおいてプログラムは停止しません。
ignore bnum count
continue
コマンドを使用して実行を再開する場合、
ignore
コマンドを使用することなく、
直接continue
コマンドの引数に通過カウントを指定することができます。
継続実行とステップ実行を参照してください。
ブレイクポイントが通過カウントとして正の値を持ち、
かつ、
成立条件を持つ場合、
成立条件はチェックされません。
通過カウントが0に達すると、
GDBは成立条件のチェックを再開します。
`$foo-- <= 0'のように、
評価の度に値の減少するデバッガのコンビニエンス変数を使用した評価式によって、
通過カウントと同様の効果を達成することができます。
コンビニエンス変数を参照してください。
ブレイクポイント (もしくはウォッチポイント) に対して、 それによってプログラムが停止した時に実行される一連のコマンドを指定することができます。 例えば、 ある特定の式の値を表示したり、 他のブレイクポイントを有効化したりできると便利なこともあるでしょう。
commands [bnum]
... command-list ...
end
end
だけから成る1行を記述します。
ブレイクポイントからすべてのコマンドを削除するには、
commands
行に続いて
(コマンドを一つも指定せずに)
end
を記述します。
引数bnumが指定されない場合、
commands
は最後に設定されたブレイクポイントもしくはウォッチポイントを対象とします
(最後に到達したブレイクポイントではありません)。
command-listを記述中は、 RETキーが持つ、 最後に実行されたコマンドを繰り返し実行する機能は無効です。
ブレイクポイント・コマンドを使用してプログラムの実行を再開することができます。
continue
、
step
、
あるいは実行を再開させるその他のコマンドを使用してください。
コマンド・リストの中で、
実行を再開するコマンドのあとに記述されているものは無視されます。
というのは、
プログラムが実行を再開すると
(たとえそれがnext
コマンドやstep
コマンドによるものであっても)
別のブレイクポイントに到達する可能性があり、
そのブレイクポイントがコマンド・リストを持っていると、
どちらのリストを実行するべきか曖昧になるからです。
コマンド・リストの先頭に指定されたコマンドがsilent
であると、
ブレイクポイントで停止した時に通常出力されるメッセージは表示されません。
これは、
ある特定のメッセージを出力するだけで実行を継続するようなブレイクポイントを設定するのに望ましいでしょう。
コマンド・リスト中の後続のコマンドがどれもメッセージを出力しない場合、
ブレイクポイントに到達したことをユーザに示すものは何もないことになります。
silent
はブレイクポイント・コマンド・リストの先頭においてのみ意味を持ちます。
echo
、
output
、
printf
の各コマンドを使用することで、
細かく管理された出力を表示することができます。
これらのコマンドは、
silent
指定のブレイクポイントで使うと便利です。
制御された出力を得るためのコマンドを参照してください。
例えば、
ブレイクポイント・コマンドを使用して、
foo
へのエントリにおいて
x
が正の値を持つ時に、
その値を表示するには以下のようにします。
break foo if x>0 commands silent printf "x is %d\n",x cont end
ブレイクポイント・コマンドの一つの応用として、
あるバグの持つ影響を取り除いて、
他のバグを見つけるためにテストを継続することができます。
誤りのある行の次の行にブレイクポイントを設定し、
その条件の中で誤りの発生を検査し、
ブレイクポイント・コマンドの中で修正の必要な変数に正しい値を割り当てます。
コマンド・リストの最後にはcontinue
コマンドを記述して、
プログラムが停止しないようにします。
また、
プログラムの先頭にはsilent
コマンドを記述し、
何も出力されないようにします。
以下に例を挙げます。
break 403 commands silent set x = y + 4 cont end
プログラミング言語によっては
(特に C++ の場合)、
同一の関数名を異なるコンテキストにおいて使用するために、
複数回定義することが可能です。
これは、
オーバローディングと呼ばれます。
関数名がオーバロードされている場合、
`break function'だけでは、
どこにブレイクポイントを設定したいのかをGDBに正しく指定するのに十分ではありません。
このような場合には、
ブレイクポイントを設定したい関数がどれであるかを正確に指定するために、
`break function(types)'のような形式を使用することができます。
このような形式を使用しないと、
GDBは候補となりえるブレイクポイントの一覧を番号付きのメニューとして表示し、
プロンプト`>'によってユーザの選択を待ちます。
先頭の二つの選択肢は常に、
`[0] cancel'と`[1] all'です。
1を入力すると、
候補となるすべての関数のそれぞれの定義に対してブレイクポイントを設定します。
また、
0を入力すると、
新たにブレイクポイントを設定することなく
break
コマンドをアボートします。
例えば、
以下のセッション抜粋は、
オーバロードされたシンボルString::after
に対してブレイクポイントを設定しようとした場合を示しています。
ここでは、
この関数名を持つ関数定義の中から三つを選択しています。
(gdb) b String::after [0] cancel [1] all [2] file:String.cc; line number:867 [3] file:String.cc; line number:860 [4] file:String.cc; line number:875 [5] file:String.cc; line number:853 [6] file:String.cc; line number:846 [7] file:String.cc; line number:735 > 2 4 6 Breakpoint 1 at 0xb26c: file String.cc, line 867. Breakpoint 2 at 0xb344: file String.cc, line 875. Breakpoint 3 at 0xafcc: file String.cc, line 846. Multiple breakpoints were set. Use the "delete" command to delete unwanted breakpoints. (gdb)
継続実行とは、
ユーザ・プログラムの実行を再開して、
それが正常に終了するまで実行させることを指します。
一方、
ステップ実行とは、
ユーザ・プログラムを1「ステップ」だけ実行することを指します。
ここで「ステップ」とは、
(使用されるコマンドによって)
ソースコード1行を指すこともありますし、
1マシン命令を指すこともあります。
継続実行の場合でもステップ実行の場合でも、
ブレイクポイントやシグナル
のためにユーザ・プログラムが正常終了する前に停止することがあります
(シグナルによってプログラムが停止した場合、
実行を再開するには
handle
コマンドもしくは`signal 0'
コマンドを使用するとよいでしょう。
シグナルを参照してください)
。
continue [ignore-count]
c [ignore-count]
fg [ignore-count]
ignore
コマンドと似た効果を持ちます
(ブレイクポイントの成立条件を参照)。
引数ignore-countは、
ユーザ・プログラムがブレイクポイントによって停止した場合にのみ意味を持ちます。
これ以外の場合には、
continue
コマンドへの引数は無視されます。
c
およびfg
は、
簡便さのためだけに提供されている同義コマンドで、
continue
コマンドとまったく同様の動作をします。
別の箇所で実行を再開するには、
呼び出し関数に戻るreturn
コマンド
(関数からの復帰を参照)、
もしくは、
ユーザ・プログラム内の任意の箇所へ移動するためのjump
コマンド
(異なるアドレスにおける処理継続を参照)
を使用することができます。
ステップ実行の典型的な使用方法は、 問題があると思われる関数あるいはプログラム部分の先頭にブレイクポイントを設定 (ブレイクポイント、ウォッチポイント、例外を参照) し、 ブレイクポイントで停止するまでプログラムを実行させた後、 問題が再現するまで、 関連しそうな変数の値を調べながら疑わしい部分を一行ずつ実行することです。
step
s
です。
現在注意: デバッグ情報なしでコンパイルされた関数の内部にいる時に
step
コマンドを使用すると、 デバッグ情報付きの関数に達するまでプログラムの実行は継続されます。 同様に、step
コマンドはデバッグ情報なしでコンパイルされた関数の内部へ入って、 停止することはありません。 デバッグ情報を持たない関数の内部でステップ実行を行うには、 後述のstepi
コマンドを使用してください。
step
コマンドは、
ソースコード行の最初の命令においてのみ停止します。
これにより、
以前のバージョンで発生した、
switch
文やfor
文等において複数回停止してしまうという問題が回避されています。
行の中にデバッグ情報を持つ関数への呼び出しがあると、
step
コマンドは続けて停止します。
さらに、現在のstep
コマンドは、
サブルーチンが行番号情報を持つ場合に限り、
サブルーチンの内部に入り込みます。
サブルーチンが行番号情報を持たない場合、
step
コマンドはnext
コマンドと同様の動作をします。
これにより、
MIPSマシン上でcc -gl
を使用した場合に発生していた問題が回避されています。
以前のバージョンでは、
サブルーチンが何らかのデバッグ情報を持っていれば、
その内部に入り込んでいました。
step count
step
コマンドによるステップ実行をcount回繰り返します。
ステップ実行をcount回繰り返し終わる前に、
ブレイクポイントに到達する
か、
もしくは、
ステップ実行とは関連のないシグナルが発生した
場合には、
ただちにステップ実行を中断して停止します。
next [count]
step
コマンドと似ていますが、
next
コマンドは、
ソースコード上に関数呼び出しが存在すると、
その関数を停止することなく最後まで実行します。
プログラムが停止するのは、
next
コマンドを実行した時と同一のスタック・フレーム上において、
ソースコード上異なる行まで実行が継続された時です。
このコマンドの省略形はn
です。
引数countは、
step
コマンドの場合と同様、
繰り返し回数です。
現在next
コマンドは、
ソースコード行の最初の命令においてのみ停止します。
これにより、
以前のバージョンで発生した、
swtch文やfor文等において複数回停止してしまうという問題が回避されています。
finish
return
コマンド
(関数からの復帰を参照)
とこれを比較してみてください。
u
until
next
コマンドに似ていますが、
唯一の相違点は、
until
コマンドによる実行中にジャンプ命令が実行された場合、
プログラム・カウンタの値がジャンプ命令のアドレスより大きくなるまで、
プログラムが継続実行されるという点です。
これは、
ステップ実行によってループ内の最後の行に到達した後にuntil
コマンドを実行することで、
ループから抜け出るまでプログラムを継続実行させることができるということを意味しています。
これに対して、
ループ内の最後の行でnext
コマンドを実行すると、
プログラムはループの先頭に戻ってしまうので、
ループ内の処理を繰り返すことを余儀なくされます。
until
コマンドの実行により、
プログラムがカレントなスタック・フレームから抜け出ようとすると、
そこでuntil
コマンドはプログラムを停止します。
実行されるマシン・コードの順序がソース行の順序と一致しない場合、
until
コマンドは直観にいくらか反するような結果をもたらすかもしれません。
例えば、
以下に挙げるデバッグ・セッションからの抜粋では、
f
(frame
)
コマンドによって、
プログラムが206
行めにおいて停止していることが示されています。
しかるに
until
コマンドを実行すると、
195
行めで停止します。
(gdb) f #0 main (argc=4, argv=0xf7fffae8) at m4.c:206 206 expand_input(); (gdb) until 195 for ( ; argc > 0; NEXTARG) {これはコンパイラが、 実行の効率を高めるために、 C言語では
for
ループ本体の前に記述されているループ終了のための条件判定を、
ループの先頭ではなく末尾で行うコードを生成したためです。
この判定式にまで処理を進めた時、
until
コマンドはあたかもループの先頭に戻ったかのように見えます。
しかしながら、
実際のマシン・コードのレベルでは、
前の命令に戻った訳ではありません。
引数なしのuntil
コマンドは、
1命令ごとのステップ実行によって実現されるため、
引数付きの
until
コマンドに比べて処理性能が劣ります。
until location
u location
break
コマンドの受け付ける形式の引数です
(ブレイクポイントの設定を参照)。
この形式によるbreak
コマンドはブレイクポイントを使用するため、
引数なしのuntil
コマンドより処理性能が優れています。
stepi
si
step
コマンドと同様、
繰り返し回数を取ります。
nexti
ni
next
コマンドと同様、
繰り返し回数を取ります。
シグナルは、
プログラム内で発生する非同期イベントです。
オペレーティング・システムが、
使用可能なシグナルの種類を定義し、
それぞれに名前と番号を割り当てます。
例えば、
UNIXにおいては、
割り込み
(通常は、Ctrlキーを押しながらCを押す)
を入力した時にプログラムが受信する
SIGINT
、
その使用領域からかけ離れたメモリ域を参照した時にプログラムが受信するSIGSEGV
、
アラームのタイムアウト時に発生する
(プログラムからアラームを要求した場合にのみ発生する)
SIGALRM
シグナルなどがあります。
SIGALRM
など、
いくつかのシグナルは、
プログラムの正常な機能の一部です。
SIGSEGV
などの他のシグナルは、
エラーを意味します。
これらのシグナルは、
プログラムが事前にそれを処理する何らかの方法を指定しないと、
致命的な
(プログラムを即座に終了させる)
ものとなります。
SIGINT
はユーザ・プログラム内部のエラーを意味するものではありませんが、
通常は致命的なものであり、
よって割り込みの目的であるプログラムの終了を実現することができます。
GDBは、 ユーザ・プログラム内部における任意のシグナル発生を検出することができます。 ユーザは、 個々のシグナルの発生時に何を実行するかを、 GDBに対して事前に指定することができます。
通常GDBは、
SIGALRM
のようなエラーではないシグナルを無視するよう
(これらのシグナルがユーザ・プログラムの中で持っている役割を妨害することのないよう)
設定されています。
その一方で、
エラーのシグナルが発生した場合にはすぐにユーザ・プログラムを停止させるよう設定されています。
これらの設定はhandle
コマンドによって変更することができます。
info signals
info handle
はinfo signals
に対して設定された新しい別名です。
handle signal keywords...
handle
コマンドが受け付けるキーワードには省略形を使用することができます。
省略しない場合、
キーワードは以下のようになります。
nostop
stop
print
キーワードを暗黙のうちに含みます。
print
noprint
nostop
キーワードを暗黙のうちに含みます。
pass
nopass
シグナルによってユーザ・プログラムが停止する時、
そのシグナルは実行を継続するまで認識できません。
その時点において、
そのシグナルに対してpass
キーワードが有効であれば、
ユーザ・プログラムは実行継続時にシグナルを検出します。
言い換えれば、
GDBがシグナルの発生を報告してきた時、
handle
コマンドでpass
もしくはnopass
を使用することで、
実行を継続した時にプログラムにそのシグナルを検出させるか否かを管理することができます。
またsignal
コマンドを使用することによって、
ユーザ・プログラムがシグナルを検出できないようにしたり、
通常は検出できないシグナルを検出できるようにしたり、
あるいは任意の時点で任意のシグナルをユーザ・プログラムに検出させたりすることができます。
例えば、
ユーザ・プログラムが何らかのメモリ参照エラーによって停止した場合、
ユーザは、
さらに実行を継続しようとして、
問題のある変数に正しい値を設定して継続実行しようとするかもしれません。
しかし、
実行継続直後に検出される致命的なシグナルのために、
おそらくユーザ・プログラムはすぐに終了してしまうでしょう。
このようなことを回避したければ、
`signal 0'コマンドによって実行を継続することができます。
ユーザ・プログラムへのシグナルの通知を参照してください。
ユーザ・プログラムが複数のスレッドを持つ場合 (マルチスレッド・プログラムのデバッグを参照)、 すべてのスレッドにブレイクポイントを設定するか、 特定のスレッドにブレイクポイントを設定するかを選択することができます。
break linespec thread threadno
break linespec thread threadno if ...
break
コマンドに修飾子`thread threadno'を使用することで、
ある特定のスレッドがこのブレイクポイントに到達した時だけGDBがプログラムを停止するよう、
指定することができます。
ここで
threadnoは
GDBによって割り当てられるスレッド識別番号で、
`info threads'コマンドによる出力の最初の欄に表示されるものです。
ブレイクポイントを設定する際に`thread threadno'を指定しなければ、
そのブレイクポイントはユーザ・プログラム内部のすべてのスレッドに適用されます。
条件付きのブレイクポイントに対してもthread
識別子を使用することができます。
この場合、
以下のように`thread threadno'をブレイクポイント成立条件の前に記述してください。
(gdb) break frik.c:13 thread 28 if bartab > lim
いかなる理由によるのであれGDB配下においてユーザ・プログラムが停止した場合、 カレント・スレッドだけではなく、 すべての実行スレッドが停止します。 これにより、 知らないうちに状態の変化が発生することを心配することなく、 スレッドの切り替えなども含めたプログラム全体の状態を検査することができます。
逆に、
プログラムの実行を再開した時には、
すべてのスレッドが実行を開始します。
これは、
step
コマンドやnext
コマンドによるシングル・ステップ実行の場合でも同様です。
特にGDBは、 すべてのスレッドの歩調を合わせてシングル・ステップ実行することはできません。 スレッドのスケジューリングは、 デバッグを行うマシンのオペレーティング・システムに依存する (GDBが管理するわけではない) ので、 カレント・スレッドがシングル・ステップの実行を完了する前に、 他のスレッドは複数の文を実行してしまうかもしれません。 さらに言えば、 プログラムが停止する時、 他のスレッドは2つの文の間の境界のところでぴったり停止するよりも、 文の途中で停止してしまう方が一般的です。
また、 継続実行やステップ実行の結果、 プログラムが別のスレッド内で停止してしまうこともありえます。 継続実行あるいはステップ実行されたスレッドがユーザの要求した処理を完了する前に、 他のスレッドがブレイクポイントに到達した場合、 シグナルを受信した場合、 例外が発生した場合などに、 このようなことが発生します。
ユーザ・プログラムが停止した時、 まず最初に、 どこで停止したのか、 そして、 どのようにしてそこに到達したのかを知る必要があるでしょう。
ユーザ・プログラムが関数呼び出しを行う度に、 その呼び出しに関する情報が生成されます。 その情報には、 ユーザ・プログラム内においてその呼び出しが発生した場所、 関数呼び出しの引数、 呼び出された関数内部のローカル変数などが含まれます。 その情報は、 スタック・フレームと呼ばれるデータ・ブロックに保存されます。 スタック・フレームは、 呼び出しスタックと呼ばれるメモリ域に割り当てられます。
ユーザ・プログラムが停止すると、 スタックを検査するGDBコマンドを使用して、 この情報をすべて見ることができます。
GDBは1つのスタック・フレームを選択していて、 多くのGDBコマンドはこの選択されたフレームを暗黙のうちに参照します。 特に、 GDBに対してユーザ・プログラム内部の変数の値を問い合わせると、 GDBは選択されたフレームの内部においてその値を探そうとします。 関心のあるフレームを選択するための特別なGDBコマンドが提供されています。 フレームの選択を参照してください。
ユーザ・プログラムが停止すると、
GDBは自動的にその時点において実行中のフレームを自動的に選択し、
コマンドframe
(フレームに関する情報を参照)
のように、
そのフレームに関する情報を簡潔に表示します。
呼び出しスタックは、 スタック・フレームもしくは短縮してフレームと呼ばれる連続した小部分に分割されます。 個々のフレームは、 一つの関数呼び出しに関連するデータです。 フレームは、 関数への引数、 関数のローカル変数、 関数の実行アドレスなどを含みます。
ユーザ・プログラムが起動された時、
スタックにはmain
関数のフレームが一つ存在するだけです。
これは、
初期フレームもしくは「最も外側のフレーム」と呼ばれます。
関数が呼ばれる度に、
新たにフレームが作成されます。
関数が復帰すると、
その関数を呼び出した時に生成されたフレームが取り除かれます。
関数が再帰的に呼び出される場合、
一つの関数に対して多くのフレームが生成されるということもありえます。
実際に実行中の関数に対応するフレームは、
「最も内側のフレーム」と呼ばれます。
これは、
その時点において存在するすべてのスタック・フレームの中で、
最も新しく作成されたものです。
ユーザ・プログラムの内部においては、 スタック・フレームはアドレスによって識別されます。 スタック・フレームは多くのバイトから構成され、 それらは一つ一つそれ自身のアドレスを持っています。 あらゆるコンピュータは、 そのアドレスがフレームのアドレスとなる1バイトを選択する慣習的な方法を提供しています。 通常、 あるフレーム内部で実行中は、 そのフレームのアドレスがフレーム・ポインタ・レジスタと呼ばれるレジスタに格納されています。
GDBは、 既存のスタック・フレームのすべてに番号を割り当てます。 最も内側のフレームは0で、 これを起点として、 それを呼び出したフレームを1というように順番に値を割り当てます。 これらの番号はユーザ・プログラム内部には実際には存在しません。 これらの番号は、 GDBコマンドでスタック・フレームを指定することができるように、 GDBによって割り当てられたものです。
コンパイラによっては、
スタック・フレームを使用せずに実行できるように関数をコンパイルする方法を提供しているものもあります
(例えば、
gcc
のオプション`-fomit-frame-pointer'を指定するとフレームのない関数を生成します)。
これは、
フレームをセットアップする時間を節約するために、
頻繁に利用されるライブラリ関数に対してしばしば適用されます。
これらの関数の呼び出しを扱うためにGDBが提供する機能は限られています。
最も内側のフレームの関数呼び出しがスタック・フレームを持たない場合、
GDBはあたかもそれが通常どおり番号0の別のフレームを持つかのようにみなして、
関数呼び出しの連鎖を跡づけることができるようにします。
しかしながら、
これ以外のスタック位置においてフレームを持たない関数がある場合、
GDBは特別な処置を取りません。
frame args
frame
コマンドによって、
あるスタック・フレームから別のスタック・フレームに移動し、
選択したスタック・フレームを表示させることができます。
argsは、
フレームのアドレスもしくはスタック・フレーム番号です。
引数なしで実行すると、
frame
コマンドはカレントなスタック・フレームを表示します。
select-frame
select-frame
コマンドによって、
フレームを表示することなく、
あるスタック・フレームから別のスタック・フレームに移動することができます。
これは、
frame
コマンドから、
表示処理を取り除いたものです。
バックトレースとは、 ユーザ・プログラムが現在いる箇所にどのようにして到達したかを示す要約情報です。 複数のフレームが存在する場合、 1フレームの情報を1行に表示します。 現在実行中のフレーム (番号0のフレーム) を先頭に、 それを呼び出したフレーム (番号1のフレーム) を次行に、 以降、 同様にスタックをさかのぼって情報を表示します。
backtrace
bt
backtrace n
bt n
backtrace
コマンドと似ていますが、
最も内側のフレームから数えてn個のフレームだけが表示されます。
backtrace -n
bt -n
backtrace
コマンドと似ていますが、
最も外側のフレームから数えてn個のフレームだけが表示されます。
backtrace
の別名としては、
ほかにwhere
やinfo stack
(省略形はinfo s
)
があります。
backtrace
コマンドの出力結果の各行に、
フレーム番号と関数名が表示されます。
set print address off
コマンドを実行していなければ、
プログラム・カウンタ値も表示されます。
backtrace
コマンドの出力結果では、
関数への引数に加えて、
ソース・ファイル名や行番号も表示されます。
行番号で指定される行の最初のコードを指している場合は、
プログラム・カウンタ値は省略されます。
以下にbacktrace
の例を示します。
これは、
`bt 3'の出力であり、
したがって最も内側のフレームから3フレームが表示されています。
#0 m4_traceon (obs=0x24eb0, argc=1, argv=0x2b8c8) at builtin.c:993 #1 0x6e38 in expand_macro (sym=0x2b600) at macro.c:242 #2 0x6840 in expand_token (obs=0x0, t=177664, td=0xf7fffb08) at macro.c:71 (More stack frames follow...)
番号0のフレームを表示する行の先頭には、
プログラム・カウンタ値がありません。
これは、
ユーザ・プログラムがbuiltin.c
の993
行めの最初のコードにおいて停止したことを表しています。
スタックやユーザ・プログラム内の他のデータを調べるためのほとんどのコマンドは、 それが実行された時点において選択されているスタック・フレーム上で動作します。 以下に、 スタック・フレームを選択するためのコマンドを列挙します。 どのコマンドも、 それによって選択されたスタック・フレームに関する簡単な説明を最後に表示します。
frame n
f n
main
のフレームです。
frame addr
f addr
frame
に指定する必要があります。
MIPS、
Alpha の両アーキテクチャでは、
スタック・ポインタ、
プログラム・カウンタの2つが必要です。
29kアーキテクチャでは、
レジスタ・スタック・ポインタ、
プログラム・カウンタ、
メモリ・スタック・ポインタの3つのアドレスが必要です。
up n
down n
down
は省略してdo
とすることができます。
これらのコマンドはいずれも、 最後にフレームに関する情報を2行で表示します。 1行めには、 フレーム番号、 関数名、 引数、 ソース・ファイル名、 そのフレーム内において実行停止中の行番号が表示されます。 2行めには、 実行停止中のソース行が表示されます。
以下に、 例を示します。
(gdb) up #1 0x22f0 in main (argc=1, argv=0xf7fffbf4, env=0xf7fffbfc) at env.c:10 10 read_input_file (argv[i]);
この情報が表示されたあとで、
list
コマンドを引数なしで実行すると、
フレーム内で実行停止中の行を中心に10行のソース行が表示されます。
ソース行の表示を参照してください。
up-silently n
down-silently n
up
コマンド、
down
コマンドの変種です。
相違点は、
ここに挙げた2つのコマンドが、
新しいフレームに関する情報を表示することなく実行されるという点にあります。
これらは、
情報の出力が不必要で邪魔ですらある、
GDBのコマンド・スクリプトの中での使用を主に想定したものです。
すでに挙げたもの以外にも、 選択されたフレームに関する情報を表示するコマンドがいくつかあります。
frame
f
f
と省略できます。
引数付きの場合、
このコマンドはスタック・フレームの選択に使用されます。
フレームの選択を参照してください。
info frame
info f
info frame addr
info f addr
frame
コマンドに指定するのと同様のアドレスを
(アーキテクチャによっては複数)
指定する必要があります。
フレームの選択を参照してください。
info args
info locals
info catch
up
、
down
、
frame
コマンドを使用して)
移動してから、
info catch
を実行します。
ブレイクポイントと例外を参照してください。
MIPSベースのコンピュータは変ったスタック・フレームを使用しています。 そのため、 関数の先頭を見つけるために、 GDBは時々オブジェクト・コードを逆方向に検索する必要があります。
応答時間を改善するために (特に、 このような検索を実行するために、 速度の遅いシリアル回線を使用するほかない、 組み込みアプリケーションの場合)、 以下に列挙するコマンドを使用して検索量を制限するとよいでしょう。
set heuristic-fence-post limit
show heuristic-fence-post
これらのコマンドは、 GDBがMIPSプロセッサ上のプログラムをデバッグするよう設定されている場合にのみ、 使用することができます。
GDBは、 ユーザ・プログラムのソース・コードの一部を表示することができます。 これは、 プログラムの中に記録されているデバッグ情報によって、 そのプログラムをビルドするのにどのソース・ファイルが使用されたかをGDBが知ることができるからです。 ユーザ・プログラムが停止すると、 GDBは自発的にプログラムが停止した行を表示することができます。 同様に、 ユーザがあるスタック・フレーム (フレームの選択を参照) を選択すると、 そのフレームにおいて実行が停止している行をGDBは表示します。 明示的にコマンドを使用することで、 ソース・ファイルの他の部分を表示することも可能です。
GDBをGNU Emacsインターフェイス経由で使用しているユーザは、 Emacs の提供する機能を使ってソース・ファイルを参照する方を好むかもしれません。 これについては、 GNU Emacs 内での GDB の使用を参照してください。
ソース・ファイル内の行を表示するには、
list
コマンド
(省略形はl
)
を使用します。
デフォルトでは、
10行が表示されます。
ソース・ファイルのどの部分を表示するかを決定する方法がいくつかあります。
list
コマンドの最もよく使われる形式を以下に示します。
list linenum
list function
list
list
コマンドによって表示されたのであれば、
その最後の行の次の行以降が表示されます。
しかし、
既に表示された最後の行が、
スタック・フレーム
(スタックの検査を参照)
の表示の一部として1行だけ表示されたのであれば、
その行の前後の行が表示されます。
list -
list
コマンドを上記の形式のいずれかによって実行すると、
GDBはデフォルトでは10行のソース行を表示します。
これはset listsize
コマンドによって変更することができます。
set listsize count
list
コマンドで表示される行数をcountに設定します
(list
コマンドの引数で他の値が明示的に指定された場合は、
この設定は効きません)。
show listsize
list
コマンドが表示する行数を表示します。
list
コマンドを実行後、
RETキーによってlist
コマンドを実行した場合、
引数は破棄されます。
したがって、
これは単にlist
と入力して実行したのと同じになります。
これは、
同じ行を繰り返し表示するよりも役にたつでしょう。
ただし、
引数`-'は例外となります。
この引数は繰り返し実行の際に維持されるので、
繰り返し実行することで、
ソース・ファイルの内容がさかのぼって表示されていきます。
一般的には、
list
コマンドはユーザが0個、
1個、
もしくは2個のlinespecsを指定することを期待しています。
ここでlinespecとは、
ソース行を指定するものです。
いくつかの記述方法がありますが、
いずれも結果的には何らかのソース行を指定するものです。
list
コマンドの引数として使用できる引数の完全な説明を以下に示します。
list linespec
list first,last
list ,last
list first,
list +
list -
list
以下に、 単一のソース行を指定する方法を示します。 これは、 いずれもlinespecです。
number
list
コマンドの引数に2つのlinespecがある場合、
このlinespecは最初のlinespecのソース・ファイルと同一のものを指定します。
+offset
list
コマンドにおいて、
これが第2のlinespecとして使用される場合、
第1のlinespecからoffsetで指定される行数だけ下の行を指定します。
-offset
filename:number
function
filename:function
*address
カレントなソース・ファイル内において正規表現による検索を行うためのコマンドが2つあります。
forward-search regexp
search regexp
list
コマンドによって表示された行の1つ下の行から、
1行ずつ正規表現regexpによる検索を行います。
正規表現にマッチするものが見つかると、
その行を表示します。
`search regexp'という同義語を使うことができますし、
コマンド名をfo
と省略することもできます。
reverse-search regexp
list
コマンドによって表示された行の1つ上の行から、
1行ずつ逆方向に向かって正規表現regexpによる検索を行います。
正規表現にマッチするものが見つかると、
その行を表示します。
コマンド名をrev
と省略することができます。
実行形式プログラムは、 それがコンパイルされたソース・ファイルの名前のみを記録して、 それらソース・ファイルの存在するディレクトリ名を記録しないことがあります。 また、 ディレクトリ名が記録された場合でも、 コンパイル時とデバッグ時との間に、 そのディレクトリが移動してしまっている可能性があります。 GDBは、 ソース・ファイルを検索すべきディレクトリの一覧を持っています。 これは、 ソース・パスと呼ばれます。 GDBは、 ソース・ファイルが必要な時にはいつでも、 それが見つかるまで、 このリストの中のすべてのディレクトリを記述されている順に探します。 実行ファイルのサーチ・パスは、 この目的では使用されないことに気をつけてください。 またカレントな作業ディレクトリも、 それがたまたまソース・パスの中にある場合を除けば、 この目的で使用されることはありません。
GDBがソース・パスの中でソース・ファイルを見つけることができない場合、 プログラムがディレクトリ名を記録してあれば、 そのディレクトリも検索されます。 ソース・パスにディレクトリの指定がなく、 コンパイルされたディレクトリの名前も記録されていない場合、 GDBは最後の手段としてカレント・ディレクトリを探します。
ソース・パスを再設定もしくは再調整した場合には、 ソース・ファイルの存在場所や個々の行のファイル内の位置等、 GDBが内部でキャッシュしている情報は消去されます。
GDBの起動時には、
ソース・パスにはディレクトリの指定がありません。
ディレクトリをソース・パスに追加するには、
directory
コマンドを使用してください。
directory dirname ...
dir dirname ...
directory
show directories
ソース・パスの中に、 もはや関心の対象ではないディレクトリが混在していると、 GDBが誤ったバージョンのソースを見つけてしまい、 混乱をもたらすことがあります。 以下の手順によって、 正常な状態にすることができます。
directory
コマンドを引数なしで実行します。
directory
コマンドに適切な引数を指定して実行します。
すべてのディレクトリを、
1回のコマンド実行で追加することができます。
info line
コマンドを使用してソース行をプログラム・アドレスに
(あるいは、
プログラム・アドレスをソース行に)
対応付けすることができます。
あるいは、
disassemble
コマンドを使用してあるアドレス範囲をマシン命令として表示することもできます。
GNU Emacsモードにおいて実行されている場合は、
現在のinfo line
コマンドは指定された行を示す矢印を表示します。
また、
info line
コマンドは、
アドレスを16進形式だけではなくシンボリック形式でも表示します。
info line linespec
list
コマンド
(ソース行の表示を参照)
が理解できる任意の形式によってソース行を指定することができます。
例えば、
info line
コマンドによって、
関数m4_changequote
の最初の行に対応するオブジェクト・コードの位置を知ることができます。
(gdb) info line m4_changecom Line 895 of "builtin.c" starts at pc 0x634c and ends at 0x6350.
また、
(linespecの形式として*addr
を使用することで)
ある特定のアドレスがどのソース行に含まれるのかを問い合わせることができます。
(gdb) info line *0x63ff Line 926 of "builtin.c" starts at pc 0x63e4 and ends at 0x6404.
info line
の実行後、
x
コマンドのデフォルト・アドレスは、
その行の先頭アドレスに変更されます。
これにより、
マシン・コードの調査を開始するには`x/i'を実行するだけで十分となります
(メモリの調査を参照)。
また、
このアドレスはコンビニエンス変数$_
の値として保存されます
(コンビニエンス変数を参照)。
disassemble
disassemble
コマンドを使用して、
info line
コマンドを説明した際に示した例で表示されたオブジェクト・コードの範囲を検査することができます
(ここでは、
SPARCのマシン命令が示されています)。
(gdb) disas 0x63e4 0x6404 Dump of assembler code from 0x63e4 to 0x6404: 0x63e4 <builtin_init+5340>: ble 0x63f8 <builtin_init+5360> 0x63e8 <builtin_init+5344>: sethi %hi(0x4c00), %o0 0x63ec <builtin_init+5348>: ld [%i1+4], %o0 0x63f0 <builtin_init+5352>: b 0x63fc <builtin_init+5364> 0x63f4 <builtin_init+5356>: ld [%o0+4], %o0 0x63f8 <builtin_init+5360>: or %o0, 0x1a4, %o0 0x63fc <builtin_init+5364>: call 0x9288 <path_search> 0x6400 <builtin_init+5368>: nop End of assembler dump.
set assembly-language instruction-set
disassemble
コマンド、
もしくは、
x/i
コマンドによってプログラムの逆アセンブルを行う際に使う命令セットを選択します。
これは、
複数のネイティブ命令セットを持つアーキテクチャにおいて役に立ちます。
現在のところ、
これは Intel x86 ファミリに対してのみ定義されています。
instruction-set は i386
もしくは i8086
に設定することができます。
デフォルトは i386
です。
ユーザ・プログラムの中のデータを調べる通常の方法は、
print
コマンド
(省略形はp
)
もしくはそれと同義のコマンドである
inspect
コマンドを使用することです。
これは、
ユーザ・プログラムの記述された言語
(異なる言語の使用を参照)
による式を評価し、
その値を出力するものです。
print exp
print /f exp
print
print /f
データを調べるためのより低レベルの方法はx
コマンドを使うことです。
これは、
指定されたアドレスのメモリ上のデータを指定された形式で表示するものです。
メモリの調査を参照してください。
型に関する情報や構造体
、クラス
のフィールドがどのように宣言されているかという点に関心があるのであれば、
print
コマンドではなくptype exp
コマンドを使用してください。
シンボル・テーブルの検査を参照してください。
print
および他の多くのGDBコマンドは式を受け取り、
その値を評価します。
ユーザの使用しているプログラミング言語によって定義されている定数、
変数、
演算子はいずれもGDBにおける式の中で有効です。
これには、
条件式、
関数呼び出し、
キャスト、
文字列定数が含まれます。
しかし、
プリプロセッサの#define
コマンドによって定義されるシンボルは、
残念ながら含まれません。
現在のGDBは、
ユーザの入力する式において、
配列定数をサポートします。
その構文は、
{element, element...}です。
例えば、
コマンドprint {1, 2, 3}
を使用して、
ターゲット・プログラム内でmalloc()
によって獲得されたメモリ内に配列を作成することができます。
C言語は大変広汎に使用されているので、 このマニュアルの中で示される例の中の式はC言語で記述されています。 他の言語での式の使い方に関する情報については、 異なる言語の使用を参照してください。
この節では、 プログラミング言語によらずGDBの式で使用できる演算子を説明します。
キャストは、 C言語のみならず、 すべての言語でサポートされています。 これは、 メモリ内のあるアドレスにある構造体を調べるのに、 数値をポインタにキャストするのが大変便利であるからです。
プログラミング言語によらず共通に使用可能な演算子に加えて、 GDBは以下の演算子をサポートしています。
@
::
{type} addr
最も一般的に使用される式は、 ユーザ・プログラム内部の変数名です。
式の中の変数は、 選択されたスタック・フレーム (フレームの選択を参照) 内において解釈されます。 これは、 以下の2つのいずれかとなります。
あるいは
つまり、
以下の例において、
ユーザ・プログラムが関数foo
を実行中は、
変数a
を調べたり使用したりすることができますが、
変数b
を使用したり調べたりすることができるのは、
b
が宣言されているブロックの内部をユーザ・プログラムが実行中である場合に限られます。
foo (a) int a; { bar (a); { int b = test (); bar (b); } }
ただし、 これには1つ例外があります。 スコープが単一のソース・ファイルであるような変数や関数は、 たとえ現在の実行箇所がそのファイルの中ではなくても、 参照することができます。 しかし、 このような変数もしくは関数が (異なるソース・ファイル中に) 同じ名前で複数個存在するということがありえます。 このような場合、 その名前を参照すると予期できない結果をもたらします。 2つのコロンを並べる記法によって、 特定の関数もしくはファイルの中の静的変数を指定することができます。
file::variable function::variable
ここでfileもしくはfunctionは、
静的変数variableのコンテキスト名です。
ファイル名の場合は、
引用符を使用することによってGDBがファイル名を確実に1つの単語として解釈するようにします。
例えば、
ファイル`f2.c'の中で定義されたグローバル変数x
の値を表示するには、
(gdb) p 'f2.c'::x
のようにします。
この`::'の使用が、 これと非常によく似たC++における`::'の使用と衝突することは非常に稀です。 GDBは、 式の内部においてC++のスコープ解釈演算子の使用もサポートしています。
注意:時々、 新しいスコープに入った直後やスコープから出る直前に、 関数内部のある箇所においてローカル変数が正しくない値を持つかのように見えることがあります。 マシン命令単位でステップ実行を行っているときに、 このような問題を経験することがあるかもしれません。
これは、 ほとんどのマシンでは、 (ローカル変数定義を含む) スタック・フレームのセットアップに複数の命令が必要となるからです。 マシン命令単位でステップ実行を行う場合、 スタック・フレームが完全に構築されるまで、 変数は正しくない値を持っているかのように見えることがあります。 スコープから出る時には、 スタック・フレームを破棄するのに、 通常複数のマシン命令が必要とされます。 それらの命令群をステップ実行後には、 ローカル変数の定義は既に存在しないかもしれません。
メモリ内に連続的に配置されている同一型のオブジェクトを表示することが役にたつことがよくあります。 配列の一部や動的にサイズの決定される配列で、 プログラム内部にそこへのポインタしか存在しないような場合です。
これは、 二項演算子`@'を使用して、 連続したメモリ範囲を人工配列として参照することで可能です。 `@'の左側のオペランドは、 参照したい配列の最初の要素で、 かつ、 1個のオブジェクトでなければなりません。 また、 右側のオペランドはその配列の参照したい長さでなければなりません。 結果は、 その要素がすべて左側の引数と同型である配列の値です。 第1の要素は左側の引数そのものです。 第2の要素は、 第1の要素を保持するメモリ域の直後のメモリ上から取られます。 これ以降の要素も同様です。 以下に例を示します。 プログラムが以下のようになっているとしましょう。
int *array = (int *) malloc (len * sizeof (int));
以下を実行することで、
array
の内容を表示することができます。
p *array@len
`@'の左側のオペランドは、 メモリ上に実在するものでなければなりません。 このような方法で`@'によって作成された配列の値は、 要素のインデックスの見地からは他の配列と同様に振舞い、 式の中で使用された場合は強制的にポインタとして扱われます。 人工配列は、 1度表示された後、 値ヒストリ (値ヒストリを参照) を通して式の中に現れることがよくあります。
人工配列を作成するもう1つの方法は、 キャストを使用することです。 これによって、 ある値を配列として解釈し直します。 この値は、 メモリ上に実在するものでなくてもかまいません。
(gdb) p/x (short[2])0x12345678 $1 = {0x1234, 0x5678}
ユーザの便宜を考慮して、 配列の長さが省略された場合 (例えば、 `(type[])value')、 その値を満たすサイズを (`sizeof(value)/sizeof(type)'のように) GDBが計算します。
(gdb) p/x (short[])0x12345678 $2 = {0x1234, 0x5678}
時には人工配列の機構では十分でないことがあります。
かなり複雑なデータ構造では、
関心のある要素が連続的に並んでいないことがあります。
例えば、
配列の中のポインタの値に関心がある場合です。
このような状況において役に立つ回避策の1つに、
最初の関心ある要素を表示する式の中のカウンタとしてコンビニエンス変数
(コンビニエンス変数を参照)
を使用し、
RETキーによってその式を繰り返し実行することです。
例えば、
構造体へのポインタの配列dtab
があり、
個々の構造体のフィールドfv
の値に関心があるとしましょう。
以下に、
このような場合に使える例を示します。
set $i = 0 p dtab[$i++]->fv RET RET ...
デフォルトでは、 GDBはデータの型にしたがって値を表示します。 時には、 これが望ましくない場合もあるでしょう。 例えば、 数値を16進で表示したい場合やポインタを10進で表示したい場合があるでしょう。 あるいは、 メモリ内のある特定のアドレスのデータを文字列や命令として見たい場合もあるでしょう。 このようなことをするためには、 値を表示するときに出力フォーマットを指定します。
出力フォーマットの最も単純な使用方法は、
既に評価済みの値の表示方法を指定することです。
これは、
print
コマンドの最初の引数をスラッシュとフォーマット文字で開始することで行います。
サポートされているフォーマット文字は、
以下のとおりです。
x
d
u
o
t
a
(gdb) p/a 0x54320 $3 = 0x54320 <_initialize_vx+396>
c
f
例えば、 プログラム・カウンタの値を16進数で表示する (レジスタを参照) には、 以下を実行してください。
p/x $pc
スラッシュの前にはスペースが必要ではないことに注目してください。 これは、 GDBのコマンド名にはスラッシュは含めることができないからです。
値ヒストリの最後の値を異なる形式で再表示するには、
print
コマンドに式を指定せずにフォーマットのみを指定して実行します。
例えば、
`p/x'を実行すると最後の値を16進で再表示します。
コマンドx
(examineのxです)
を使用することで、
ユーザ・プログラム内のデータ型に関わらず、
メモリ上の値をいくつかの形式で調べることができます。
x/nfu addr
x addr
x
x
コマンドを使用してください。
n、 f、 uはいずれも、 どれだけのメモリをどのようにフォーマットして表示するかを指定するオプションのパラメータです。 addrは、 メモリの表示を開始するアドレスを指定する式です。 nfuにデフォルトを使用するのであれば、 スラッシュ`/'は必要ありません。 いくつかのコマンドによって、 addrに対して便利なデフォルト値を指定することができます。
print
コマンドによって使用されるフォーマット、
`s'(NULL文字で終了する文字列)、
`i'(マシン命令)
のいずれかを指定します。
最初のデフォルトは`x'
(16進)
です。
デフォルトは、
ユーザがx
コマンドもしくはprint
コマンドを実行するたびに変更されます。
b
h
w
g
x
コマンド実行時に単位の大きさを指定するたびに、
その大きさが次にx
コマンドを実行する際のデフォルトになります
(フォーマット`s'および
`i'については、
単位の大きさは無視されます。
これらについては、
通常、
単位の大きさを記述しません)。
info breakpoints
(デフォルトは、
最後に表示されたブレイクポイントのアドレスに設定されます)、
info line
(デフォルトは、
行の先頭アドレスに設定されます)、
およびprint
コマンド
(メモリ内の値を表示するのに使用した場合)
がそのコマンドです。
例えば、
`x/3uh 0x54320'は、
先頭アドレス0x54320
から始めて、
メモリ上の3個のハーフ・ワード
(h
)
の値を、
符号無し10進整数値
(`u')
としてフォーマットして表示するよう求める要求です。
また、
`x/4xw $sp'はスタック・ポインタ
(`$sp'については、
レジスタを参照)
より上位の4ワード
(`w')
のメモリの内容を16進
(`x')
で表示します。
単位の大きさを示す文字と出力フォーマットを指定する文字とは異なるので、 単位の大きさとフォーマットのどちらが前に来るべきかを記憶しておく必要はありません。 どちらを先に記述しても動作します。 `4xw'という出力指定と`4wx'という出力指定とは、 まったく同一の意味を持ちます (ただし、 繰り返し回数nは最初に指定されなければなりません。 `wx4'ではうまく動きません)。
単位の大きさuは、
フォーマット`s'および`i'については無視されますが、
繰り返し回数nを使用したいことがあるかもしれません。
例えば、
`3i'はオペランドも含めて3つのマシン命令を表示したいということを指定しています。
disassemble
コマンドは、
マシン命令を調べる別の方法を提供してくれます。
ソースとマシン・コードを参照してください。
x
コマンドへの引数のデフォルトはすべて、
x
コマンドを使用してメモリ上を連続的に参照するために最少の情報だけを指定すればよいように設計されています。
例えば、
`x/3i addr'によってマシン命令を調べた後、
`x/7'とするだけで続く7個のマシン命令を調べることができます。
RETキーによってx
コマンドを繰り返し実行する場合は、
前回の繰り返し回数nが再度使用されます。
その他の引数も後続のx
コマンド使用時のデフォルトになります。
x
コマンドによって表示されるアドレスや内容は値ヒストリに保存されません。
これらの数がしばしば膨大になり、
邪魔になるからです。
その代りにGDBは、
これらの値をコンビニエンス変数$_
および$__
の値として、
後続の式の内部で使用できるようにします。
x
コマンドを実行後、
最後に調べられたアドレスはコンビニエンス変数$_
の値として式の中で使用することができます。
また、
GDBによって調べられたそのアドレスの内容は、
コンビニエンス変数$__
の値として使用可能です。
x
コマンドに繰り返し回数が指定されている場合、
保存されるアドレスおよびそのアドレスの内容は、
最後に表示されたメモリ単位のそれとなります。
最後の出力行にいくつかのメモリ単位が表示されている場合、
これは最後に表示されたアドレス値とは一致しません。
ある1つの式の値を (それがどのように変化するかを見るために) 頻繁に表示したい場合は、 その式を自動表示リストに加えて、 ユーザ・プログラムが停止するたびに、 GDBがその値を表示するようにするとよいでしょう。 リストに加えられた個々の式には、 それを識別するための番号が割り当てられます。 ある式をリストから削除する際、 その番号を指定します。 自動表示は、 以下のようになります。
2: foo = 38 3: bar[5] = (struct hack *) 0x3804
ここでは、
項目番号、
式、
および、
その式の現在の値が表示されます。
x
コマンドやprint
コマンドによって手動で表示を要求する場合と同様、
好みの出力フォーマットを指定することができます。
実は、
display
コマンドは、
ユーザのフォーマットの指定の詳細度によって、
print
コマンドとx
コマンドのいずれを使用するかを決定しています。
ユーザが単位の大きさを指定した場合やx
コマンドでしかサポートされていない2つのフォーマット
(`i'と`s')
のいずれかを指定した場合にはx
コマンドが使用されます。
それ以外の場合は、
print
コマンドが使用されます。
display exp
display
コマンドは繰り返し実行されません。
display/fmt exp
display/fmt addr
例えば、 `display/i $pc'は、 ユーザ・プログラムが停止するたびに次に実行されるマシン命令を見るのに便利です (`$pc'はプログラム・カウンタを指すのに一般に使用される名前です。 レジスタを参照)。
undisplay dnums...
delete display dnums...
undisplay
コマンドを実行後RETキーを押しても、
コマンドは再実行されません
(仮に、
再実行されてしまうとすると、
`No display number ...'というエラーになるだけです)。
disable display dnums...
enable display dnums...
display
info display
表示される式がローカル変数への参照を含む場合、
そのローカル変数がセットアップされているコンテキストの範囲外では、
その式は無意味です。
このような式は、
その中の変数の1つが定義されないコンテキストが実行開始されると表示不可になります。
例えば、
引数last_char
を取る関数の内部でdisplay last_char
コマンドを実行すると、
GDBはその関数の内部でユーザ・プログラムが実行を停止し続ける間は、
この引数を表示します。
ほかの箇所
(last_char
という変数が存在しない箇所)
で停止した時には、
自動的に表示不可となります。
次にユーザ・プログラムがlast_char
が意味を持つ箇所で停止した時には、
再びその式の表示を可能にすることができます。
GDBは、 配列、 構造体、 シンボルをどのように表示するかを制御するための方法を提供しています。
これらの設定は、どのプログラミング言語で記述されたプログラムのデバッグにも便利です。
set print address
set print address on
on
です。
例として、
set print address on
の時のスタック・フレームの表示結果を示します。
(gdb) f #0 set_quotes (lq=0x34c78 "<<", rq=0x34c88 ">>") at input.c:530 530 if (lquote != def_lquote)
set print address off
set print address off
の時に前の例と同一のスタック・フレームを表示すると、
以下のようになります。
(gdb) set print addr off (gdb) f #0 set_quotes (lq="<<", rq=">>") at input.c:530 530 if (lquote != def_lquote)`set print address off'を使用することで、 GDBのインターフェイスからマシンに依存する表示を取り除くことができます。 例えば、
print address off
により、
ポインタ引数の有無にかかわらずすべてのマシン上において同一のバックトレース結果を得る筈です。
show print address
GDBがシンボリックなアドレスを表示する際には、
通常そのアドレスの前にある最も近い位置のシンボルとそこからのオフセットを表示します。
そのシンボルが、
そのアドレスを一意に識別しない場合
(例えば、
単一のファイル内でのみ有効なシンボルである場合)
には、
ユーザが確認する必要があります。
確認する1つの方法は、
例えば`info line *0x4537'のようにinfo line
コマンドを実行することです。
または、
シンボリックなアドレスを表示する時に、
一緒にソース・ファイルや行番号を表示するようGDBを設定する方法もあります。
set print symbol-filename on
set print symbol-filename off
show print symbol-filename
シンボルのソース・ファイル名と行番号を表示するのが役に立つもう1つの状況として、 コードを逆アセンブルする場合があります。 GDBが、 個々の命令に対応する行番号とソース・ファイルを表示してくれます。
また、アドレスがそれより前にある最も近いシンボルに適度に近い場合のみ、 そのアドレスをシンボリック形式で表示させたいという場合もあるでしょう。
set print max-symbolic-offset max-offset
show print max-symbolic-offset
ポインタがあるが、
それがどこを指しているか定かではない場合には、
`set print symbol-filename on'を試みてください。
こうすれば、
`p/a pointer'を使用してそのポインタが指している変数の名前とソース・ファイル上の位置が分ります。
これは、
アドレスをシンボリック形式で解釈します。
例えば、
以下の例においてGDBは、
ある変数ptt
がファイル`hi2.c'内で定義された別の変数t
を指していることを示しています。
(gdb) set print symbol-filename on (gdb) p/a ptt $4 = 0xe008 <t in hi2.c>
注意:ローカル変数を指すポインタについては、 たとえ適切な
set print
オプションが有効になっていても、 `p/a'はそのポインタによって参照される変数のシンボル名やファイル名を表示しません。
他の設定により、 異なる種類のオブジェクトがいかに表示されるかが制御されます。
set print array
set print array on
set print array off
show print array
set print elements number-of-elements
set print elements
コマンドで設定された数の要素を表示すると、
そこで表示を停止します。
この上限は、
文字列の表示にも適用されます。
number-of-elementsを0に設定すると、
無制限に表示されます。
show print elements
set print null-stop
set print pretty on
$1 = { next = 0x0, flags = { sweet = 1, sour = 1 }, meat = 0x54 "Pork" }
set print pretty off
$1 = {next = 0x0, flags = {sweet = 1, sour = 1}, \ meat = 0x54 "Pork"}これがデフォルトの形式です。
show print pretty
set print sevenbit-strings on
\
nnnという表記法で表示します。
この設定は、英語
(ASCII)
環境において、
文字の最上位ビットをマーカや「メタ」ビットとして使用する場合に最適です。
set print sevenbit-strings off
show print sevenbit-strings
set print union on
set print union off
show print union
typedef enum {Tree, Bug} Species; typedef enum {Big_tree, Acorn, Seedling} Tree_forms; typedef enum {Caterpillar, Cocoon, Butterfly} Bug_forms; struct thing { Species it; union { Tree_forms tree; Bug_forms bug; } form; }; struct thing foo = {Tree, {Acorn}};
set print union on
が有効な場合、
`p foo'は以下のような表示を行います。
$1 = {it = Tree, form = {tree = Acorn, bug = Cocoon}}また、
set print union off
が有効な場合、
`p foo'は以下のような表示を行います。
$1 = {it = Tree, form = {...}}
以下の設定は、 C++プログラムをデバッグしている時に関係があります。
set print demangle
set print demangle on
show print demangle
set print asm-demangle
set print asm-demangle on
show print asm-demangle
set demangle-style style
auto
gnu
g++
) エンコーディング・アルゴリズムに基づいてデコードします。
これが、
デフォルトです。
lucid
lcc
) エンコーディング・アルゴリズムに基づいてデコードします。
arm
cfront
によって生成された実行モジュールをデバッグするのに十分ではありません。
これを行うためには、
GDBをさらに拡張する必要があります。
foo
show demangle-style
set print object
set print object on
set print object off
show print object
set print static-members
set print static-members on
set print static-members off
show print static-members
set print vtbl
set print vtbl on
set print vtbl off
show print vtbl
print
コマンドにより表示された値は、
GDBの
値ヒストリに保存されます。
これによりユーザは、
これらの値を他の式の中で参照することができます。
値は、
シンボル・テーブルが
(例えば、
file
コマンドやsymbol-file
コマンドにより)
再読み込みされるか破棄されるまで、
維持されます。
シンボル・テーブルが変更されると、
値ヒストリが破棄されるのは、
値がシンボル・テーブル内で定義された型を参照しているかもしれないからです。
表示される値はヒストリ番号を与えられ、
この番号によって参照することができます。
この番号は1から始まる連続した整数です。
print
コマンドは、
値に割り当てられたヒストリ番号を、
値の前に`$num = 'という形で表示します。
ここで、
numがそのヒストリ番号です。
以前の任意の値を参照するには、
`$'に続けてヒストリ番号を指定します。
print
コマンドが出力に付加するラベルは、
ユーザにこのことを知らせるためのものです。
$
単体では、
ヒストリ内の最も新しい値を参照し、
$$
はその1つ前の値を参照します。
$$n
は、
最新のものから数えてn番目の値を参照します。
$$2
は$$
の1つ前の値を参照し、
$$1
は$$
と同一、
$$0
は$
と同一です。
例えば、 ユーザがたった今、 構造体へのポインタを表示し、 今度はその構造体の内容を見たいと考えているとしましょう。 この場合は、
p *$
を実行すれば十分です。
また、
連結された構造体があり、
そのメンバのnext
が次の構造体を指すポインタであるとすると、
次の構造体の内容を表示するには、
p *$.next
とします。
連結された構造体を次々に表示するには、 このコマンドを繰り返し実行すればよく、 それはRETキーによって可能です。
ここで、
ヒストリは式ではなく、
値を記録するという点に注意してください。
x
の値が4の時に、
以下のコマンドを実行すると、
print
コマンドによって値ヒストリに記録される値はx
の値が変化したにもかかわらず4のままです。
print x set x=5
show values
show values
はヒストリを変更しないという点が異なります。
show values n
show values +
show values n
を繰り返し実行するのにRETキーを押すことは、
`show values +'を実行するのとまったく同じ結果をもたらします。
ある値を保持して後に参照するために使用するコンビニエンス変数をGDBは提供しています。 これらの変数はGDB内部においてのみ存在するものです。 それらはユーザ・プログラムの中に存在するものではなく、 コンビニエンス変数を設定してもユーザ・プログラムの実行には直接影響を与えません。 したがって、 ユーザはこれを自由に使用することができます。
コンビニエンス変数名は、 先頭が`$'で始まります。 `$'で始まる名前は、 それがあらかじめ定義されたマシン固有のレジスタ名 (レジスタを参照) と重複しない限り、 コンビニエンス変数の名前として使用することができます (これに対して、 値ヒストリの参照名では`$'に続けて番号を記述します。 値ヒストリを参照してください)。
ユーザ・プログラムで変数に値を設定するのと同じように、
代入式を使用してコンビニエンス変数に値を保存することができます。
例えば、
以下のようにして、
object_ptr
が指すオブジェクトが保持する値を$foo
に保存します。
set $foo = *object_ptr
コンビニエンス変数は、
最初に使用された時に生成されますが、
新しい値を割り当てるまで、
その値は空
(void
)
です。
値はいつでも代入することによって変更可能です。
コンビニエンス変数には決まった型はありません。 コンビニエンス変数には、 既に異なる型のデータが割り当てられている場合でも、 構造体や配列を含めた任意の型のデータを割り当てることができます。 コンビニエンス変数は、 式として使用される場合には、 その時点における値の型を持ちます。
show convenience
show con
です。
コンビニエンス変数の1つの使い方に、 インクリメントされるカウンタや先へ進んでいくポインタとしての使い方があります。 例えば、 構造体配列の連続する要素のあるフィールドの値を表示したい場合、
set $i = 0 print bar[$i++]->contents
このコマンドをRETキーで繰り返し実行します。
いくつかのコンビニエンス変数がGDBによって自動的に作成され、 役に立ちそうな値が設定されます。
$_
$_
変数は
x
コマンドによって最後に調べられたアドレスに自動設定されます
(メモリの調査を参照)。
x
コマンドによって調べられるデフォルトのアドレスを提供する他のコマンドも$_
をそのアドレスに設定します。
このようなコマンドには、
info line
やinfo breakpoint
があります。
$_
の型は、
x
コマンドによって設定された場合は$__
の型へのポインタであり、
それ以外の場合はvoid *
です。
$__
$__
変数はx
コマンドによって最後に調べられたアドレスにある値に自動設定されます。
その型は、
データが表示されたフォーマットに合うように選択されます。
$_exitcode
$_exitcode
変数はデバッグされているプログラムが終了した際の終了コードに自動的に設定されます。
マシン・レジスタの内容は、
`$'で始まる名前の変数として、
式の中で参照することができます。
レジスタの名前は、
マシンによって異なります。
info registers
コマンドを使用することで、
そのマシンで使用されているレジスタの名前を知ることができます。
info registers
info all-registers
info registers regname ...
GDBは、
マシンのアーキテクチャにおけるレジスタの正規のニーモニックと衝突しない限り、
ほとんどのマシン上
(の式の中)
で利用可能な4つの「標準的」なレジスタ名を持っています。
レジスタ名$pc
と$sp
は、
プログラム・カウンタ・レジスタとスタック・ポインタを指すために使われます。
$fp
は、
カレントなスタック・フレームへのポインタを保持するレジスタを指すために使われます。
$ps
は、
プロセッサの状態を保持するレジスタを指すために使われます。
例えば、
プログラム・カウンタの値を16進数で表示するには、
以下のように実行します。
p/x $pc
あるいは、 次に実行される命令を表示するには、 以下のように実行します。
x/i $pc
また、スタック・ポインタ (3) に4を加えるには、 以下のように実行します。
set $sp += 4
可能な場合にはいつでも、
これら4つの標準的なレジスタ名が使用可能です。
ユーザのマシンが異なる正規なニーモニックを使用している場合でも、
衝突さえ起らなければ、
使用可能です。
info registers
コマンドにより、
正規名を見ることができます。
例えば、
SPARC上で
info registers
コマンドを実行すると、
プロセッサ・ステータス・レジスタは$psr
と表示されますが、
このレジスタを$ps
として参照することもできます。
レジスタがこの方法で調べられる時、 GDBは普通のレジスタの内容を常に整数値とみなします。 マシンによっては、 浮動小数点値以外を保持できないレジスタを持つものがあります。 このようなレジスタは、 浮動小数点値を持つものとみなされます。 普通のレジスタの内容を浮動小数点値として参照する方法はありません (`print/f $regname'により浮動小数点値として値を 表示することはできます)。
レジスタには、
rawとvirtualの2つの異なるデータ形式を取るものがあります。
これは、
オペレーティング・システムによってレジスタの内容が保存される時のデータ形式が、
ユーザ・プログラムが通常認識しているものと同じではないことを意味しています。
例えば、
68881浮動小数点コプロセッサのレジスタの値は常にextended
(raw)形式で保存されていますが、
C言語によるプログラムは通常double
(virtual)形式を想定しています。
このような場合、
GDBは通常
(ユーザ・プログラムにとって意味のある形式である)
virtual形式のみを扱いますが、
info registers
コマンドはデータを両方の形式で表示してくれます。
通常、 レジスタの値は、 選択されたスタック・フレーム (フレームの選択を参照) における相対値です。 これは、 ユーザにレジスタの値として見えるものは、 選択されたフレームから呼び出されているすべてのスタック・フレームが終了し、 退避されたレジスタの値が復元されたときに、 そのレジスタが持つであろう値です。 ハードウェア・レジスタの本当の値を知りたければ、 最も内側のフレームを (`frame 0'で) 選択しなければなりません。
しかし、 GDBはコンパイラが生成したコードからどこにレジスタが保存されているかを推論する必要があります。 退避されていないレジスタがある場合や、 GDBが退避されたレジスタを見つけることができない場合は、 どのスタック・フレームを選択していても結果は同じです。
set rstack_high_address address
set rstack_high_address
コマンドによってレジスタ・スタックの最終アドレスを指定することによって、
この問題を回避することができます。
引数はアドレスでなければなりません。
これは、
`0x'を先頭に記述することで16進数で指定することができます。
show rstack_high_address
設定によっては、 GDBは浮動小数ハードウェアの状態についてより詳しい情報を提供することができます。
info float
通常、
プログラミング言語というものは共通点を持つものですが、
その表記法がまったく同様であるということはめったにありません。
例えば、
ポインタ
p
の指す値を取り出す方法は、
ANSI Cでは*p
ですが、
Modula-2ではp^
です。
値の表現方法
(および表示方法)
もまた異なります。
16進数は、
Cでは`0x1ae'のようになりますが、
Modula-2では`1AEH'のようになります。
いくつかの言語については、 言語固有の情報がGDBに組み込まれており、 これにより、 プログラムを記述した言語によって上記のような操作を記述したり、 プログラムを記述した言語の構文にしたがってGDBに値を出力させることができます。 式を記述するのにユーザが使用する言語を、 作業言語と呼びます。
作業言語を制御する方法は2つあります。
GDBに自動的に設定させる方法と、
ユーザが手動で選択する方法です。
どちらの目的でも、
set language
コマンドを使用することができます。
起動時のデフォルトでは、
GDBは言語を自動的に設定します。
作業言語は、
ユーザの入力する式がどのように解釈されるか、
あるいは、
値がどのように表示されるかを決定します。
この作業言語とは別に、
GDBの認識しているすべてのソース・ファイルには、
それ自体の作業言語があります。
オブジェクト・ファイルのフォーマットによっては、
ソース・ファイルの記述された言語を示す情報をコンパイラが書き込んでいることがあるかもしれません。
しかし、
ほとんどの場合、
GDBはファイル名から言語を推定します。
ソース・ファイルの言語が、
C++シンボル名がデコード
(demangle)
されるか否かを制御します。
これにより、
backtrace
は個々のフレームをその言語にしたがって適切に表示することができます。
GDBによってソース・ファイルの言語を設定することはできません。
このことは、
他の言語で記述されたソースからCのソースを生成するcfront
やf2c
のようなプログラムをユーザが使用する場合に問題となるでしょう。
このような場合には、
生成されるCの出力に#line
指示子を使用するよう、
そのプログラムを設定してください。
こうすることによって、
GDBは元になったプログラムのソース・コードが記述された言語を正しく知ることができ、
生成されたCのコードではなく、
元になったソース・コードを表示します。
ソース・ファイル名が以下のいずれかの拡張子を持つ場合、 GDBはその言語を以下に示すものと推定します。
GDBに言語を自動的に設定させる場合、 ユーザのデバッグ・セッションとユーザのプログラムにおいて式は同様に解釈されます。
もしそうしたければ、
言語を手動で設定することもできます。
そのためには、
コマンド`set language lang'を実行します。
ここで、
langは、
c
やmodula-2
のような言語名です。
サポートされている言語のリストは、
`set language'で表示させることができます。
言語を手動で設定すると、 GDBは作業言語を自動的に更新することができなくなります。 このことは、 作業言語がソースの言語と同一ではない場合で、 ある式がどちらの言語でも有効でありながら、 その意味が異なるような状況でプログラムをデバッグしようとした時に、 混乱をもたらす可能性があります。 例えば、 カレントなソース・ファイルがC言語で記述されていて、 GDBがそれをModula-2として解析している場合に、
print a = b + c
のようなコマンドを実行すると、
その結果はユーザが意図したものとは異なるものになるでしょう。
これはC言語では、
b
とc
とを加算して、
その結果をa
に入れるということを意味し、
表示される結果は、
a
の値となります。
Modula-2では、
これはa
とb+c
の結果とを比較してBOOLEAN
型の値を出力することを意味します。
GDBに作業言語を自動的に設定させるには、 `set language local'もしくは`set language auto'を使用します。 この場合、 GDBは作業言語を推定します。 つまり、 ユーザ・プログラムが (通常はブレイクポイントに達することによって) あるフレーム内部で停止した時、 GDBは、 そのフレーム内の関数に対して記録されている言語を作業言語として設定します。 フレームの言語が不明の場合 (つまり、 そのフレームに対応する関数もしくはブロックが既知ではない拡張子を持つソース・ファイルにおいて定義されている場合)、 カレントな作業言語は変更されず、 GDBは警告メッセージを出力します。
これは、 全体がただ1つの言語のみで記述されているほとんどのプログラムにおいて不要であると思われるでしょう。 しかし、 あるソース言語で記述されたプログラム・モジュールやライブラリは、 他のソース言語で記述されたメイン・プログラムから使用することができます。 このような場合に`set language auto'を使用することで、 ユーザは作業言語を手作業で設定する手間から解放されます。
以下のコマンドは、 作業言語、 および、 ソース・ファイルの記述された言語を知りたい時に役に立ちます。
show language
print
コマンドなどでユーザ・プログラム内部の変数を含む式を構築したり評価したりすることができます。
info frame
info source
注意:現在のリリースでは、 型および範囲のチェックを行うGDBコマンドは組み込まれていますが、 それらは実際には何も実行しません。 このセクションでは、 これらのコマンドが本来持つべく意図されている機能について記述してあります。
いくつかの言語は、 一連のコンパイル時チェック、 実行時チェックによって、 一般によく見られるエラーの発生を防ぐように設計されています。 これらのチェックには、 関数や演算子への引数の型のチェックや、 数学的操作の結果のオーバフローを実行時に確実に検出することなどが含まれています。 このようなチェックは、 型の不一致を排除したり、 ユーザ・プログラムの実行時に範囲エラーをチェックしたりすることによって、 コンパイル後のプログラムの正しさを確かなものにするのに役に立ちます。
GDBは、
ユーザが望むのであれば、
上記のような条件のチェックを行います。
GDBはユーザ・プログラムの文をチェックすることはしませんが、
例えばprint
コマンドによる評価を目的としてGDBに直接入力された式をチェックすることはできます。
作業言語の場合と同様に、
GDBが自動的にチェックを行うか否かをユーザ・プログラムのソース言語によって決定することもできます。
サポートされている言語のデフォルトの設定については、
サポートされる言語を参照してください。
いくつかの言語、 例えばModula-2などは、 強く型付けされています。 これは、 演算子や関数への引数は正しい型でなくてはならず、 そうでない場合にはエラーが発生するということを意味しています。 このようなチェックは、 型の不一致のエラーが実行時に問題を発生させるのを防いでくれます。 例えば、 1+2は
1 + 2 => 3 ですが、1+2.3は error--> 1 + 2.3
とエラーになります。
第2の例がエラーになるのは、
CARDINAL
型の1はREAL
型の2.3と型の互換性がないからです。
GDBコマンドの中で使われる式については、 ユーザがGDBの型チェック機能に対して、 以下のような指示を出すことができます。
最後の指示が選択された場合、 GDBは上記の第2の例のような式でも評価しますが、 その際には警告メッセージを出力します。
型チェックをしないよう指示した場合でも、
型に関係のある原因によってGDBが式の評価ができなくなる場合がありえます。
例えば、
GDBはint
の値とstruct foo
の値を加算する方法を知りません。
これら特定の型エラーは、
使用されている言語とは関係なく、
この例のように、
そもそも評価することが意味をなさないような式に起因するものです。
個々の言語は、 それが型に関してどの程度厳密であるかを定義しています。 例えば、 Modula-2とCはいずれも、 算術演算子への引数としては数値を要求します。 Cでは、 列挙型とポインタは数値として表すことができますので、 これらは算術演算子への正当な引数となります。 特定の言語に関する詳細については、 サポートされる言語を参照してください。
GDBは、 型チェック機能を制御するためのコマンドをさらにいくつか提供しています。
set check type auto
set check type on
set check type off
set check type warn
show type
いくつかの言語 (例えば、 Modula-2) では、 型の上限を超えるとエラーとなります。 このチェックは実行時に行われます。 このような範囲チェックは、 計算結果がオーバフローしたり、 配列の要素へのアクセス時に使うインデックスが配列の上限を超えたりすることがないことを確実にすることによって、 プログラムの正しさを確かなものにすることを意図したものです。
ユーザがGDBコマンドの中で使う式については、 範囲エラーの扱いを以下のいずれかにするよう GDBに指示することができます。
範囲エラーは、 数値がオーバフローした場合、 配列インデックスの上限を超えた場合、 ユーザがどの型のメンバでもない定数を入力した場合に発生します。 しかし、 言語の中には、 数値のオーバフローをエラーとして扱わないものもあります。 C言語の多くの実装では、 数学的演算によるオーバフローは、 結果の値を「一巡」させて小さな値にします。 例えば、 mが整数値の最大値、 sが整数値の最小値とすると、
m + 1 => s
になります。
これも、 個々の言語に固有であり、 場合によっては、 個々のコンパイラやマシンに固有です。 特定の言語に関する詳細については、 サポートされる言語を参照してください。
GDBは、 範囲チェック機能を制御するためのコマンドをさらにいくつか提供しています。
set check range auto
set check range on
set check range off
set check range warn
show range
GDB 4は、C、C++、Modula-2
をサポートしています。
いくつかのGDBの機能は、
使用されている言語に関わらず式の中で使用できます。
GDBの@
演算子、
::
演算子、
および`{type}addr'
(式を参照)
は、
サポートされている任意の言語において使用することができます。
次節以降で、 個々のソース言語がGDBによってどの程度までサポートされているのかを詳しく説明します。 これらの節は、 言語についてのチュートリアルやリファレンスとなることを意図したものではありません。 むしろ、 GDBの構文解析機能が受け付ける式や、 異なる言語における正しい入出力フォーマットのリファレンス・ガイドとしてのみ役に立つものです。 個々の言語については良い書籍が数多く出ています。 言語リファレンスやチュートリアルが必要な場合は、 これらの書籍を参照してください。
CとC++は密接に関連しているので、 GDBの機能の多くは両方の言語に適用できます。このようなものについては、2つの言語を一緒に議論します。
C++のデバッグ機能は、
GNU C++コンパイラとGDBによって協同で実装されています。
したがって、
C++のコードを効率よくデバッグするには、
C++のユーザ・プログラムを
GNU C++コンパイラg++
でコンパイルする必要があります。
C++ プログラムのデバッグ時に最高の結果を引き出すには、
スタブ・デバッグ・フォーマットを使用してください。
g++
のコマンドライン・オプション`-gstabs'もしくは`-gstabs+'によって、
このフォーマットを明示的に選択することができます。
詳細については、
Using GNU CC の `Options for Debugging Your Program or GNU CC' の部分を参照してください。
演算子は、
特定の型の値に対して定義されなければなりません。
例えば、
+
は数値に対しては定義されていますが、
構造体に対しては定義されていません。
演算子はしばしば型のグループに対して定義されます。
C/C++ に対しては、以下の定義が有効です。
int
、
char
、
enum
から成ります。
float
とdouble
から成ります。
(type *)
により定義されるすべての型から成ります。
以下の演算子がサポートされています。 これらは優先順位の低いものから順に並べられています。
,
=
op=
a op= b
という形式の式において使用され、
a = a op b
に変換されます。
op=
と=
は、
同一の優先順位を持ちます。
ここで、
opには|
、
^
、
&
、
<<
、
>>
、
+
、
-
、
*
、
/
、
%
の各演算子が使用できます。
?:
a ? b : c
は、
aが真であればb、
偽であればcとみなします。
aは整数型でなければいけません。
||
&&
|
^
&
==、!=
<、>、<=、>=
<<、>>
@
+、-
*、/、%
++, --
*
++
と同一の優先度を持ちます。
&
++
と同一の優先順位を持ちます。
C++のデバッグでは、
C++自体では許されていないような`&'の使用法をGDBは実装しています。
C++の
(`&(&ref)'により宣言される)
参照変数が格納されているアドレスを調べるのに、
`&&ref'
(あるいは、もしそうしたいのであれば、
より簡単な`&ref')
を使用することができます。
-
++
と同一の優先順位を持ちます。
!
++
と同一の優先順位を持ちます。
~
++
と同一の優先順位を持ちます。
.、->
struct
)
および共用体
(union
)
に対して定義されています。
[]
a[i]
は*(a+i)
として定義されています。
->
と同一の優先順位を持ちます。
()
->
と同一の優先順位を持ちます。
::
struct
)、
共用体(union
)、
クラス(class
)に対して定義されています。
::
::
と同一の優先順位を持ちます。
GDBでは、 以下のような方法によって、 C/C++の定数を表すことができます。
long
型の値として扱われるべきことが指定されます。
'
)
によって囲まれた単一の文字、
あるいは、
その文字に対応する序数
(通常は、
ASCII値)
です。
引用符の中の単一文字は、
文字もしくはエスケープ・シーケンスによって表すことができます。
エスケープ・シーケンスには2つの表記方法があります。
第1の形式は`\nnn'で、
nnnはその文字の序数を表す8進数です。
第2の形式は`\x'で、
`x'はあらかじめ定義された特別な文字です。
例えば、
`\n'は改行を表します。
"
)
で囲まれたものです。
GDBの式処理機能にはいくつかの拡張機能があり、 これによりC++の式の重要なサブセットを解釈することができます。
注意:GDBではGNU C++コンパイラでコンパイルされたC++コードしかデバッグできません。 さらに、 C++のデバッグはシンボル・テーブルの中の追加的なデバッグ情報の使用に依存するため、 特別なサポートが必要です。 GDBはこのようなサポートをスタブ・デバッグ・フォーマットでのみ手に入れることができます。 使用されるコンパイラがa.out、 MIPS ECOFF、 RS/6000 XCOFF、 ELFを、 シンボル・テーブルへのスタブ拡張付きで生成することができるのであれば、 これらの機能を使用することができます (GNUの場合は、 `-gstabs'オプションを使用して明示的にスタブ・デバッグ拡張を要求することができます)。 一方、 オブジェクト・コードのフォーマットが標準COFFやDWARFのELFである場合には、 GDBの提供するほとんどのC++サポートは機能しません。
count = aml->GetOriginal(x, y)
this
への暗黙の参照を許します。
::
をサポートしています。
ユーザはプログラム中と同様に、
式の中でこれを使用することができます。
あるスコープが別のスコープ中で定義されることがありえるため、
必要であれば::
を繰り返し使用することができます。
例えば、
`scope1::scope2::name'という具合です。
GDBはまた、
CおよびC++のデバッグにおいて、
ソース・ファイルを参照することで名前のスコープを解決することができます
(プログラム変数を参照)。
GDBが自動的に型チェックや範囲チェックの設定を行うことを許すと、
作業言語がCもしくはC++に変更される時にはいつも、
それらの設定はデフォルトでoff
になります。
これは、
作業言語を選択したのがユーザであってもGDBであっても同様です。
GDBが自動的に言語の設定を行うことを許すと、 GDBは名前が`.c'、 `.C'、 `.cc'で終わるソース・ファイルを認識していて、 これらのファイルからコンパイルされたコードを実行し始める時に、 作業言語をCもしくはC++に設定します。 詳細については、 GDBによるソース言語の推定を参照してください。
デフォルトでは、 GDBがCもしくはC++の式を解析する時には、 型チェックは行われません。 しかし、 ユーザが型チェックを有効にすると、 GDBは以下の条件が成立する時に、 2つの変数の型が一致しているとみなします。
typedef
によって同一の型に宣言されている型を持つ。
範囲チェックは、 オンに設定されている場合、 数学的演算に対して実行されます。 配列のインデックスは、 しばしばそれ自体は配列ではないポインタのインデックスとして使用されるため、 チェックされません。
set print union
コマンドとshow print union
コマンドは共用体型
(union
)
に適用されます。
`on'に設定されると、
構造体
(struct
)
やクラス
(class
)
の内部にある任意の共用体
(union
)
は表示されます。
`on'でない場合、
それは`{...}'と表示されます。
@
オペレータは、
ポインタとメモリ割り当て関数とによって形成された動的配列のデバッグに役に立ちます。
式を参照してください。
GDBのコマンドの中にはC++を使用している時に特に役に立つものがあり、 また、 C++専用に特に設計されたものがあります。 以下に、 その要約を示します。
breakpoint menus
rbreak regex
catch exceptions
info catch
ptype typename
set print demangle
show print demangle
set print asm-demangle
show print asm-demangle
set print object
show print object
set print vtbl
show print vtbl
オーバロードされたシンボル名
symbol(types)
と入力してください。
GDBコマンドラインの単語補完機能を使用して、
利用可能な選択肢を一覧表示させたり、
型のリストを完結させたりすることができます。
この機能の使用方法の詳細については、
コマンド名の補完を参照してください。
Modula-2をサポートするために開発されたGDBの拡張機能は、 (現在開発中の) GNU Modula-2コンパイラによって生成されたコードのみをサポートします。 他のModula-2コンパイラは現在サポートされていません。 他のModula-2コンパイラで生成された実行形式モジュールをデバッグしようとすると、 おそらくGDBが実行モジュールのシンボル・テーブルを読み込もうとしたところでエラーになるでしょう。
演算子は、
特定の型の値に対して定義されなければなりません。
例えば、
+
は数値に対して定義され、
構造体に対しては定義されません。
演算子は、
しばしば型のグループに対して定義されます。
Modula-2においては、
以下の定義が有効です。
INTEGER
、
CARDINAL
および、そのサブレンジ(subrange)から成ります。
CHAR
とそのサブレンジ(subrange)から成ります。
REAL
から成ります。
POINTER TO type
のように宣言された任意の型から成ります。
SET
、
BITSET
から成ります。
BOOLEAN
から成ります。
以下の演算子がサポートされています。 ここでは、 優先順位の低いものから順に並べています。
,
:=
:=
valueの値は
valueです。
<、>
<=、>=
<
と同一の優先順位を持ちます。
=、<>、#
<
と同一の優先順位を持ちます。
GDBスクリプトの中では、
#
がスクリプトのコメント記号でもあるため、
不等価としては<>
のみが使用可能です。
IN
<
と同一の優先順位を持ちます。
OR
AND、&
@
+、-
*
/
*
と同一の優先順位を持ちます。
DIV、MOD
*
と同一の優先順位を持ちます。
-
INTEGER
、
REAL
型のデータに対して定義されています。
^
NOT
^
と同一の優先順位を持ちます。
.
RECORD
フィールドの区切記号です。
RECORD
データに対して定義されます。^
^
と同一の優先順位を持ちます。
[]
ARRAY
型のデータに対して定義されています。
^
と同一の優先順位を持ちます。
()
PROCEDURE
オブジェクトに対して定義されています。
^
と同一の優先順位を持ちます。
::、.
注意:集合および集合に対する操作はまだサポートされていません。 このため、 GDBは
IN
演算子、 および、 集合に対して+
、-
、*
、/
、=
、<>
、#
、<=
、>=
のいずれかの演算子が使用された場合、 これをエラーとして扱います。
Modula-2 ではいくつかの組込プロシージャ、組込関数が使用できます。これらの説明にあたり、以下のメタ変数を使用します。
ARRAY
型の変数を表します。
CHAR
型の定数あるいは変数を表します。
SET OF mtype
でなければなりません。
また、 すべてのModula-2の組込プロシージャは、 以下に説明する値を返します。
ABS(n)
CAP(c)
CHR(i)
DEC(v)
DEC(v,i)
EXCL(m,s)
FLOAT(i)
HIGH(a)
INC(v)
INC(v,i)
INCL(m,s)
MAX(t)
MIN(t)
ODD(i)
ORD(x)
SIZE(x)
TRUNC(r)
VAL(t,i)
注意:集合と集合に対する操作はまだサポートされていません。 したがって、
INCL
プロシージャ、EXCL
プロシージャを使用すると、 GDBはエラーとして扱います。
GDBでは、 Modula-2の定数を以下のような方法で表現することができます。
'
)もしくは2重引用符("
)で囲まれた単一文字より成ります。
文字型定数は、
その文字の
(通常はASCIIの)
序数値に続けて`C'を付加することで表現することもできます。
'
)もしくは2重引用符("
)で囲まれた連続する文字から成ります。
C言語のスタイルでのエスケープ・シーケンスも使用できます。
エスケープ・シーケンスに関する簡単な説明は、
C/C++定数を参照してください。
TRUE
およびFALSE
から成ります。
型チェックおよび範囲チェックがGDBにより自動的に設定される場合、
作業言語がModula-2に変わるたびに、
それらはデフォルトでon
に設定されます。
これは、
作業言語を選択したのがユーザであろうとGDBであろうと同様です。
GDBに自動的に言語を設定させると、 ファイル名の末尾が`.mod'であるファイルからコンパイルされたコードに入るたびに、 作業言語はModula-2に設定されます。 詳細については、 GDBによるソース言語の推定を参照してください。
Modula-2プログラムのデバッグを容易にするために2、 3の修正が施されています。 これは主に、 型に対する厳密性を緩めることによって実現されています。
:=
)
は、
右側の引数の値を返します。
注意:GDBは現在のところ型チェック、 範囲チェックをまだサポートしていません。
GDBは、 以下のいずれかの条件が成立する時、 2つのModula-2変数の型が等しいとみなします。
TYPE t1 = t2
文によって等しいと宣言されている型である。
型チェックが有効である限り、 等しくない型の変数を組み合わせようとする試みはすべてエラーとなります。
範囲チェックは、 数学的操作、 代入、 配列のインデックス境界、 およびすべての組み込み関数、 組み込みプロシージャにおいて実行されます。
::
と.
Modula-2のスコープ演算子(.
)とGDBのスコープ演算子(::
)との間には2、
3の微妙な相違点があります。
この2つは似た構文を持っています。
module . id scope :: id
ここで、 scopeはモジュール名もしくはプロシージャ名、 moduleはモジュール名、 idはユーザ・プログラムの中で宣言された任意の (異なるモジュール以外の) 識別子です。
::
演算子を使用するとGDBはscopeによって指定されたスコープにおいて識別子idを探します。
指定されたスコープにおいてそれを見つけることができないと、
GDBはscopeによって指定されたスコープを包含するすべてのスコープを探します。
.
演算子を使用するとGDBはカレントなスコープにおいて、
modueによって指定された定義モジュールから取り込まれた、
idによって指定される識別子を探します。
この演算子を使用した際に、
識別子idが定義モジュールmoduleから取り込まれていない場合やmoduleにおいてidが識別子でない場合は、
エラーになります。
GDBコマンドのなかには、
Modula-2プログラムのデバッグにはほとんど役に立たないものがいくつかあります。
set print
、
show print
の5つのサブコマンド`vtbl'、
`demangle'、
`asm-demangle'、
`object'、
`union'はC/C++にのみ適用されます。
最初の4つはC++に適用され、
最後の1つはCの共用体
(union
)
に適用されます。
これらは、
Modula-2において直接類似するものが存在しません。
@
演算子
(式を参照)
は、
どの言語においても使用することができますが、
Modula-2においてはあまり役に立ちません。
この演算子は、
動的配列のデバッグを支援することを目的とするものですが、
C/C++では作成できる動的配列は、
Modula-2では作成できません。
しかし、
整数値定数によってアドレスを指定することができるので、
`{type}adrexp'は役に立ちます
(式を参照)。
GDBスクリプトの中では、
Modula-2の不等価#
はコメントの開始記号として解釈されます。
代わりに<>
を使用してください。
ここで説明するコマンドによって、 ユーザ・プログラムの中で定義されているシンボル情報 (変数名、 関数名、 型名) に関する問い合わせを行うことができます。 この情報はユーザ・プログラムのテキストに固有のもので、 プログラムの実行時に変わるものではありません。 GDBはこの情報を、 ユーザ・プログラムのシンボル・テーブルの中、 もしくは、 GDB起動時に指定されたファイル (ファイルの選択を参照) の中で見つけるか、 ファイル管理コマンド (ファイルを指定するコマンドを参照) の実行によって見つけます。
時には、 GDBが通常は単語の区切文字として使用するような文字を含むシンボルを参照することが必要になるかもしれません。 特に多いのが、 他のソース・ファイルの中の静的変数を参照する場合です (プログラム変数を参照)。 GDBは通常、典型的なファイル名、 例えば`foo.c'を解析して、 3つの単語 `foo'、 `.'(ピリオド)、 `c'であるとみなします。 GDBが`foo.c'を単一のシンボルであると認識できるようにするには、 それを単一引用符で囲みます。 例えば、
p 'foo.c'::x
は、
x
の値をファイル`foo.c'のスコープの中で検索します。
info address symbol
whatis exp
whatis
$
のデータ型を表示します。
ptype typename
ptype exp
ptype
ptype
はwhatis
と異なります。
例えば、
次の変数宣言
struct complex {double real; double imag;} v;に対して、
whatis
、
ptype
はそれぞれ以下のような出力をもたらします。
(gdb) whatis v type = struct complex (gdb) ptype v type = struct complex { double real; double imag; }
whatis
と同様、
引数なしでptype
を使用すると、
値ヒストリの最後の値である$
の型を参照することになります。
info types regexp
info types
value
を含むすべての型に関する情報を表示し、
`i type ^value$'は名前がvalue
そのものである型に関する情報のみを表示します。
このコマンドはptype
とは2つの点で異なります。
まず第1にwhatis
と同様、
詳細な情報を表示しません。
第2に、
型が定義されているすべてのソース・ファイルを一覧表示します。
info source
info sources
info functions
info functions regexp
step
を含むすべての関数を見つけ、
`info fun ^step'は名前がstep
で始まるすべての関数を見つけます。
info variables
info variables regexp
set symbol-reloading on
set symbol-reloading off
symbol-reloading
の設定はoffのままにするべきです。
さもないと、
(異なるディレクトリやライブラリの中にある)
同じ名前を持ついくつかのモジュールを含むような大きなプログラムをリンクする際に、
GDB
はシンボルを破棄してしまうかもしれません。
show symbol-reloading
symbol-reloading
のカレントな設定
(on
またはoff
)
を表示します。
maint print symbols filename
maint print psymbols filename
maint print msymbols filename
info sources
コマンドを使用することで、
これらのファイルがどれであるかを知ることができます。
代わりに`maint print psymbols'を使用すると、
GDB
が部分的にしか知らないシンボルに関する情報もダンプの中に含まれます。
これは、
GDBがざっと読みはしたものの、
まだ完全には読み込んでいないファイルに定義されているシンボルに関する情報です。
最後に`maint print msymbols'では、
GDBが何等かのシンボル情報を読み込んだオブジェクト・ファイルから、
最小限必要とされるシンボル情報がダンプされます。
GDBがどのようにしてシンボルを読み込むかについては、
ファイルを指定するコマンド
(のsymbol-file
の説明の部分)
を参照してください。
ユーザ・プログラムの中に誤りのある箇所を見つけると、 次に、 その明らかな誤りを訂正することで、 その後の実行が正しく行われるかどうかを知りたくなるでしょう。 プログラムの実行を変更するGDBの機能を使って実験することで、 その答を知ることができます。
例えば、 変数やメモリ上のある箇所に新しい値を格納したり、 ユーザ・プログラムにシグナルを送ったり、 ユーザ・プログラムを異なるアドレスで再起動したり、 関数が完全に終了する前に呼び出し元に戻ったりすることができます。
ある変数の値を変更するには、 代入式を評価します。 式を参照してください。 例えば、
print x=4
は、
変数x
に値4を格納してから、
その代入式の値
(すなわち4)
を表示します。
サポートされている言語の演算子の詳細情報については、
異なる言語の使用を参照してください。
代入の結果を表示させることに関心がなければ、
print
コマンドの代わりにset
コマンドを使用してください。
実際のところset
コマンドは、
式の値が表示されず、
値ヒストリ
(値ヒストリを参照)
にも入らないことを除けば、
print
コマンドと同等です。
式は、
その結果の入手のみを目的として評価されます。
set
コマンドの引数となる文字列の先頭の部分が、
set
コマンドのサブコマンドの名前と一致してしまうような場合には、
ただのset
コマンドではなくset variable
コマンドを使用してください。
このコマンドは、
サブコマンドを持たないという点を除けば、
set
コマンドと同等です。
例えば、
ユーザ・プログラムにwidth
という変数がある場合、
この変数に`set width=13'によって値を設定しようとするとエラーになります。
これは、
GDBがset width
というコマンドを持っているためです。
(gdb) whatis width type = double (gdb) p width $4 = 13 (gdb) set width=47 Invalid syntax in expression.
ここで不当な表現となっているのは、
もちろん`=47'の部分です。
プログラム内の変数width
に値を設定するには、
以下のようにしてください。
(gdb) set var width=47
GDBは、 代入時の暗黙の型変換をC言語よりも多くサポートしています。 整数値を自由にポインタ型変数に格納できますし、 その逆もできます。 また、 任意の構造体を、 それと同じサイズかより小さいサイズの構造体に変換することができます。
メモリ上の任意の箇所に値を格納するには、
`{...}'を使用して、
指定されたアドレスにおいて指定された型の値を生成してください
(式を参照)。
例えば、
{int}0x83040
はメモリ・アドレス0x83040
を整数値として参照します
(メモリ上においてある特定のサイズと表現を取るということを示唆しています)。
また、
set {int}0x83040 = 4
は、 そのメモリ・アドレスに値4を格納します。
通常ユーザ・プログラムを継続実行するには、
continue
コマンドを使用して、
停止した箇所から継続実行させます。
以下のコマンドを使用することで、
ユーザが選択したアドレスにおいて実行を継続させることができます。
jump linespec
jump
コマンドは、
カレントなスタック・フレーム、
スタック・ポインタ、
メモリ内の任意の箇所の内容、
プログラム・カウンタを除くレジスタの内容を変更しません。
linespecで指定される行が、
その時点において実行されている関数とは異なる関数の中にある場合、
それら2つの関数が異なるパターンの引数やローカル変数を持つ場合、
奇妙な結果が発生するかもしれません。
このため、
指定された行が、
その時点において実行されている関数の中にない場合、
jump
コマンドは実行の確認を求めてきます。
しかし、
ユーザがプログラムのマシン言語によるコードを熟知していたとしても、
奇妙な結果の発生することが予想されます。
jump *address
レジスタ$pc
に新しい値を設定することで、
jump
コマンドとほとんど同等の効果を実現することができます。
相違は、
レジスタ$pcへの値の設定は、
ユーザ・プログラムの実行を再開しないという点にあります。
ユーザが実行を継続する時に、
プログラムが実行を再開するアドレスが変更されるだけです。
例えば、
set $pc = 0x485
によって、
次にcontinue
コマンドやステップ実行を行うコマンドが実行される時、
ユーザ・プログラムが停止したアドレスにある命令ではなく、
アドレス0x485
にある命令から実行されることになります。
継続実行とステップ実行を参照してください。
jump
コマンドが最も一般的に使用されるのは、
既に実行されたプログラムのある部分を、
さらに多くのブレイクポイントを設定した状態で再度実行する場合でしょう。
これにより、
実行される処理の内容をさらに詳しく調べることができます。
signal signal
signal 2
とsignal SIGINT
はともに割り込みシグナルを通知する方法になります。
一方、
signalが0であれば、
シグナルを通知することなく実行を継続します。
ユーザ・プログラムがシグナルのために停止させられ、
continue
コマンドによって実行を再開すると通常はそのシグナルを検知してしまうような場合に便利です。
`signal 0'を実行すると、
プログラムはシグナルを受信することなく実行を再開します。
signal
を実行した後、
RETキーを押しても、
繰り返し実行は行われません。
signal
コマンドを実行することは、
シェルからkill
ユーティリティを実行するのと同じではありません。
kill
によってシグナルを送ると、
GDBはシグナル処理テーブルによって何をするべきかを決定します
(シグナルを参照)。
一方、
signal
コマンドは、
ユーザ・プログラムに直接シグナルを渡します。
return
return expression
return
コマンドによって、
関数呼び出しの実行をキャンセルすることができます。
式expressionを引数に指定すると、
その値が関数の戻り値として使用されます。
ユーザがreturn
を実行すると、
GDBは選択されているスタック・フレーム
(および、
その内部のすべてのフレーム)
を破棄します。
破棄されたフレームは、
実行を完結する前に復帰したのだと考えればよいでしょう。
戻り値を指定したいのであれば、
その値をreturn
への引数として渡してください。
このコマンドは、 選択されているスタック・フレーム (フレームの選択を参照)、 およびその内部のすべてのフレームをポップして、 もともと選択されていたフレームを呼び出したフレームを、 最も内側のフレームにします。 つまり、 そのフレームが選択されることになります。 指定された値は、 関数から戻り値を返すのに使用されるレジスタに格納されます。
return
コマンドは実行を再開しません。
関数から復帰した直後の状態でプログラムが停止したままにします。
これに対して、
finish
コマンド
(継続実行とステップ実行を参照)は、
選択されているスタック・フレームが自然に復帰するまで、
実行を再開、
継続します。
call expr
void
型の戻り値を表示することなく、
式exprを評価します。
ユーザ・プログラムの中からある関数を呼び出したいが、
void型の戻り値を出力させたくない場合、
このprint
コマンドの変種を使用することができます。
戻り値がvoid
型でない場合には、
それは表示され、
値ヒストリに保存されます。
ユーザの制御する新しい変数call_scratch_addressが、 GDBがターゲット中の関数を呼び出すときに使用するスクラッチ領域を指定します。 通常はスクラッチ領域をスタック上に置きますが、 この方法は命令空間とデータ空間とが異なるシステム上では機能しないため、 これが必要になります。
デフォルトでは、 GDBはユーザ・プログラムの実行コードを含むファイル (あるいは、 コア・ファイル) を書き込み不可の状態でオープンします。 これにより、 マシン・コードを誤って変更してしまうことを防ぐことができます。 しかし、 ユーザ・プログラムのバイナリに意図的にパッチを適用することもできなくなってしまいます。
バイナリにパッチを適用したいのであれば、
set write
コマンドによって明示的にそれを指定することができます。
例えば、
内部的なデバッグ・フラグを立てたり、
緊急の修正を行いたいということがあるでしょう。
set write on
set write off
set write
の設定を変更後、
その変更を反映させるためには、
(exec-file
コマンド
、
core-file
コマンド
を使用して)、
そのファイルを再ロードしなければなりません。
show write
GDBはデバッグ対象となるプログラムのファイル名を知っている必要があります。 これは、 プログラムのシンボル・テーブルを読み込むためでもあり、 また、 プログラムを起動するためでもあります。 過去に生成されたコア・ダンプをデバッグするには、 GDBにコア・ダンプ・ファイルの名前を教えてやらなければなりません。
実行ファイルやコア・ダンプ・ファイルの名前を指定したい場合があります。 これは通常、 起動時にGDBの起動コマンドへの引数を利用して行います (GDBの起動・終了を参照)。
時には、 GDBのセッション中に、 異なるファイルに切り替える必要がでてくることがあります。 あるいは、 GDBを起動する時に、 使いたいファイルの名前を指定するのを忘れたということもあるかもしれません。 このような場合に、 新しいファイルを指定するGDBコマンドが便利です。
file filename
run
コマンドを使用した時に実行されます。
ユーザがディレクトリを指定せず、
そのファイルがGDBの作業ディレクトリに見つからない場合、
シェルが実行すべきファイルを探す時と同様、
GDBは環境変数PATH
の値をファイルを探すべきディレクトリのリストとして使用します。
GDB、
ユーザ・プログラムの両方について、
この変数の値をpath
コマンドによって変更することができます。
ファイルをメモリにマップすることのできるシステムでは、
補助的なファイル`filename.syms'が、
ファイルfilenameのシンボル・テーブル情報を格納することができます。
このような場合、
GDBは`filename.syms'というファイルからシンボル・テーブルをメモリ上にマップすることで、
起動に要する時間を短くします。
詳細については、
ファイル・オプションの`-mapped'、
`-readnow'
(これらは、
コマンドライン上で、
以下に説明するfile
、
symbol-file
、
add-symbol-file
コマンドで使用できます)
の説明を参照してください。
file
file
コマンドを引数なしで実行すると、
GDBは実行ファイル、
シンボル・テーブルに関して保持している情報をすべて破棄します。
exec-file [ filename ]
PATH
を使用します。
filenameを指定しないと、
実行ファイルに関して保持している情報を破棄することを意味します。
symbol-file [ filename ]
PATH
が検索されます。
同一のファイルから、
シンボル・テーブルと実行プログラムの両方を獲得する場合には、
file
コマンドを使用してください。
symbol-file
を引数なしで実行すると、
ユーザ・プログラムのシンボル・テーブルに関してGDBが持っている情報が消去されます。
symbol-file
が実行されると、
それまでGDBが保持していたコンビニエンス変数、
値ヒストリ、
すべてのブレイクポイント、
自動表示式は破棄されます。
これらの情報の中には、
GDBが破棄した古いシンボル・テーブルのデータの一部であるシンボルやデータ型を記録する内部データへのポインタが含まれているかもしれないからです。
symbol-file
を一度実行した後にRETキーを押しても、
symbol-file
の実行は繰り返されません。
GDBは、
特定の環境用に設定されると、
その環境において生成される標準のフォーマットにおけるデバッグ情報を理解するようになります。
GNUコンパイラを使うこともできますし、
ローカルな環境の規約に従う他のコンパイラを使用することもできます。
通常はGNUコンパイラを使用している時に、
最高の結果を引き出すことができます。
例えば、
gcc
を使うと最適化されたコードに対してデバッグ情報を生成することができます。
ある種のオブジェクト・ファイルにおいては、
symbol-file
コマンドを実行しても、
通常はただちにシンボル・テーブルの全体が読み込まれる訳ではありません。
存在するソース・ファイル名とシンボル名とを知るために、
シンボル・テーブルを素早く調べるだけです。
詳細な情報は、
後にそれが必要になった時に、
一度に1ソース・ファイルずつ読み込まれます。
2段階に分けて読み込むこの手法の目的は、
GDBの起動時間の短縮です。
ほとんどの場合、
特定のソース・ファイルに関するシンボル・テーブルの詳細が読み込まれている間の若干の停止を除けば、
このような手法を採用しているということを示すものはありません
(もしそうしたいのであれば、
set verbose
コマンドを使うことによって、
これらの停止をメッセージとして表示させることもできます。
オプションの警告およびメッセージを参照してください)。
COFFについては、
まだこの2段階方式を実装していません。
シンボル・テーブルが
COFFフォーマットで格納されている場合、
symbol-file
コマンドはシンボル・テーブル・データの全体をただちに読み込みます。
symbol-file filename [ -readnow ] [ -mapped ]
file filename [ -readnow ] [ -mapped ]
mmap
システム・コールによるファイルのメモリへのマッピングがシステム上において有効な場合、
もう1つのオプション
`-mapped'を使って、
GDBにユーザ・プログラムのシンボルを再利用可能なファイルに書き込ませることができます。
後のGDBデバッグ・セッションは、
(プログラムに変更がない場合)
実行プログラムからシンボル・テーブルを読み込むのに時間を費やすことなく、
この補助シンボル・ファイルからシンボル情報をマップします。
`-mapped'オプションを使用することは、
コマンドライン・オプション`-mapped'を指定してGDBを起動するのと同等の効果を持ちます。
補助シンボル・ファイルがユーザ・プログラムのシンボル情報をすべて確実に持つように、
両方のオプションを同時に指定することもできます。
myprogという名のプログラムの補助シンボル・ファイルは、
`myprog.syms'という名になります。
このファイルが存在すると、
(それが、
対応する実行ファイルよりも新しい限り)
ユーザがmyprogをデバッグしようとするとGDBは常にそのファイルを使おうとします。
特別なオプションやコマンドは必要ありません。
`.syms'ファイルは、
GDBを実行したホスト・マシンに固有のものです。
それは、
GDB内部におけるシンボル・テーブルの正確なイメージを保持しています。
複数のホスト・プラットフォーム間で共用することはできません。
core-file [ filename ]
core-file
を引数なしで実行すると、
コア・ファイルを一切使用しないことを指定したことになります。
ユーザ・プログラムが実際にGDBの管理下で実行中の場合は、
コア・ファイルは無視されることに注意してください。
したがって、
ある時点までユーザ・プログラムを実行させた後に、
コア・ファイルをデバッグしたくなったような場合、
プログラムを実行しているサブ・プロセスを終了させなければなりません。
サブ・プロセスの終了は、
kill
コマンドで行います
(子プロセスの終了を参照)。
load filename
load
コマンドが使用可能になります。
これが利用可能な場合、
実行ファイルfilenameが
(例えば、
ダウンロードやダイナミック・リンクによって)
リモート・システム上でデバッグできるようになることを意味します。
また、
load
コマンドはadd-symbol-file
コマンドと同様、
ファイルfilenameのシンボル・テーブルをGDB内に記録します。
GDBがload
コマンドを提供していない場合、
それを実行しようとすると
「You can't do that when your target is ...
」
というエラー・メッセージが表示されます。
実行ファイルの中で指定されたアドレスにファイルはロードされます。
オブジェクト・ファイルのフォーマットによっては、プログラムをリンクする時に、
ファイルをロードするアドレスを指定できるものもあります。
このようなフォーマット以外
(例えば、
a.out)
では、
オブジェクト・ファイルのフォーマットによって固定的にアドレスが指定されます。
VxWorksでload
コマンドを実行すると、
filenameで指定される実行ファイルがカレントなターゲット・システム上で動的にリンクされ、
シンボルがGDBに追加されます。
Intel 960ボードのNindyインターフェイスでは、
load
コマンドはfilenameで指定されるファイルをダウンロードし、
そのシンボルをGDBに追加します。
日立のSH、
H8/300、
H8/500ボード
(GDBと日立のマイクロ・プロセッサを参照)
に対するリモート・デバッグを選択すると、
load
コマンドはユーザ・プログラムを日立ボードにダウンロードし、
(file
コマンドと同様)
ユーザのホスト・マシン上のGDBのカレントなターゲット実行モジュールとしてオープンします。
load
コマンドを実行後RETキーを押しても、
load
コマンドは繰り返し実行されません。
add-symbol-file filename address
add-symbol-file filename address [ -readnow ] [ -mapped ]
add-symbol-file
コマンドは、
filenameで指定されるファイルから追加的なシンボル・テーブル情報を読み込みます。
実行中のプログラムが
(何か別の方法によって)
filenameで指定されるファイルを動的にロードした場合に、
このコマンドを使用します。
addressは、
ファイルがロードされたメモリ・アドレスでなければなりません。
GDBは独力でこのアドレスを知ることはできません。
addressは式として指定することもできます。
filenameで指定されるファイルのシンボル・テーブルは、
もともとsymbol-file
コマンドによって読み込まれたシンボル・テーブルに追加されます。
add-symbol-file
コマンドは何回でも使用することができます。
新たに読み込まれたシンボル・テーブルのデータは、
古いデータに追加されていきます。
古いシンボル・データをすべて破棄するには、
symbol-file
コマンドを使用してください。
add-symbol-file
コマンドを実行後RETキーを押しても、
add-symbol-file
コマンドは繰り返し実行されません。
symbol-file
コマンドと同様、
`-mapped'オプションと`-readnow'オプション使用して、
filenameで指定されるファイルのシンボル・テーブル情報をGDBがどのように管理するかを変更することができます。
add-shared-symbol-file
add-shared-symbol-file
コマンドは、
Motorola 88k用のHarris' CXUXオペレーティング・システム上でのみ使用することができます。
GDBは自動的に共有ライブラリを探しますが、
GDBがユーザの共有ライブラリを見つけてくれない場合、
add-shared-symbol-file
コマンドを実行できます。
このコマンドは引数を取りません。
section
section
コマンドは、
実行ファイルのsectionセクションのベース・アドレスをaddrに変更します。
これは、
(a.outフォーマットのように)
実行ファイルがセクション・アドレスを保持していない場合や、
ファイル内に指定されたアドレスが誤っている場合に使うことができます。
個々のセクションは、
個別に変更されなければなりません。
`info files'コマンドによって、
すべてのセクションとそのアドレスを一覧表示することができます。
info files
info target
info files
とinfo target
は同義です。
両方とも、
カレント・ターゲット
(デバッグ・ターゲットの指定を参照)
に関する情報を表示します。
表示される情報には、
GDBがその時点で使用している実行ファイル
やコア・ダンプ・ファイル
の名前、
シンボルがそこからロードされたファイルの名前を含みます。
help target
コマンドは、
カレントなターゲットではなく、
すべての可能なターゲットを一覧表示します。
ファイルを指定するコマンドはすべて、 引数として絶対パスでのファイル名と相対パスでのファイル名の両方を取ることができます。 GDBはファイル名を常に絶対パス名に変換し、 絶対パスの形で記憶します。
GDBは、
SunOS、
SVr4、
Irix5、
IBM RS/6000の共有ライブラリをサポートします。
ユーザがrun
コマンドを実行したり、
コア・ファイルを調べようとすると、
GDBは自動的に共有ライブラリからシンボル定義をロードします
(ユーザがrun
コマンドを発行するまでは、
GDBは共有ライブラリ内部の関数への参照を理解しません。
コア・ファイルをデバッグしている場合は、
この限りではありません)。
info share
info sharedlibrary
sharedlibrary regex
share regex
run
コマンド実行時に必要とされる共有ライブラリのみをロードします。
regexが省略されると、
ユーザ・プログラムによって必要とされるすべての共有ライブラリがロードされます。
シンボル・ファイルを読み込み中に、
GDBは時々問題にぶつかることがあります。
例えば、
認識できないシンボル・タイプを見つけたり、
コンパイラの出力に既知の問題を発見することがあります。
デフォルトでは、
GDBはこのようなエラーがあったことをユーザに知らせません。
何故なら、
このようなエラーは比較的よく見られるものであり、
コンパイラのデバッグをしているような人々のみが関心を持つようなものだからです。
もし、
正しく構築されていないシンボル・テーブルに関する情報を見ることに関心があれば、
set complaints
コマンドを使用することで、
何回問題が発生しようと個々のタイプの問題について一回だけメッセージを出力するよう指示することもできますし、
何回問題発生したかを見るためにより多くのメッセージを表示するよう指示することもできます
(オプションの警告およびメッセージを参照)。
現在のバージョンで表示されるメッセージとその意味を以下に記します。
inner block not inside outer block in symbol
(don't know)
'のように表示されることがあります。
block at address out of order
set verbose on
を指定することで、
どのソース・ファイルが関係しているかを知ることができます。
オプションの警告およびメッセージを参照してください)。
bad block start address patched
bad string table offset in symbol n
foo
という名前を持つものとみなすことによって、
この問題を回避します。
この結果、
多くのシンボルがこの名前を持つことになってしまうと、
ほかの問題が発生する可能性があります。
unknown symbol type 0xnn
0xnn
は理解できなかったシンボルの型を16進数で表したものです。
GDBは、
このようなシンボル情報を無視することによって、
このエラーを回避します。
この場合、
ユーザはプログラムのデバッグを行うことは可能ですが、
ある特定のシンボルにアクセスすることができなくなります。
このような問題にぶつかり、
それをデバッグしたいのであれば、
gdb
自身を使ってgdb
をデバッグすることができます。
この場合、
シンボルcomplain
にブレイクポイントを設定し、
関数read_dbx_symtab
まで実行してから、
*bufp
によってシンボルを参照します。
stub type has NULL name
const/volatile indicator missing (ok if using g++ v1.x), got...
info mismatch between compiler and debugger
ターゲットとは、
ユーザ・プログラムの実行環境を指します。
多くの場合、
GDBはユーザ・プログラムと同一のホスト環境上で実行されます。
この場合には、
file
コマンドやcore
コマンドを実行すると、
その副作用としてデバッグ・ターゲットが指定されます。
例えば、
物理的に離れた位置にあるホスト・マシン上でGDBを実行したい場合や、
シリアル・ポート経由でスタンドアロン・システムを制御したい場合、
もしくは、
TCP/IP接続を利用してリアルタイム・システムを制御したい場合などのように、
より多くの柔軟性が必要とされる場合、
target
コマンドを使ってGDBに設定されたターゲットの種類から1つを指定することができます
(ターゲットを管理するコマンドを参照)。
ターゲットには3つのクラスがあります。 プロセス、コア・ファイル、 そして、 実行ファイルです。 GDBは同時に、 1クラスにつき1つ、 全体で最高で3つまでアクティブなターゲットを持つことができます。 これにより、 (例えば) コア・ファイルに対して行ったデバッグ作業を破棄することなく、 プロセスを起動してその動作を調べることができます。
例えば、
`gdb a.out'を実行すると、
実行ファイルa.out
が唯一のアクティブなターゲットになります。
コア・ファイル
(恐らくは、
前回実行した時にクラッシュしコア・ダンプしたもの)
を併せて指定すると、
GDBは2つのターゲットを持ち、
メモリ・アドレスに対する要求を満足するために、
まずコア・ファイルを参照し、
次に実行ファイルを参照するという具合に、
2つのターゲットを並行して使用します
(典型的には、
これら2つのクラスのターゲットは相互に補完的です。
というのも、
コア・ファイルはプログラムが読み書き可能な変数等のメモリとマシン・ステータスのみを持ち、
実行ファイルはプログラムのテキストと初期化されたデータのみを持つからです)。
run
コマンドを実行すると、
ユーザの実行ファイルはアクティブなプロセス・ターゲットにもなります。
プロセス・ターゲットがアクティブな間は、
メモリ・アドレスを要求するすべてのGDBコマンドは、
プロセス・ターゲットを参照します。
アクティブなコア・ファイル・ターゲットや
実行ファイル・ターゲットの中のアドレスは、
プロセス・ターゲットがアクティブな間は隠されます。
新しいコア・ファイル・ターゲットや実行ファイル・ターゲットを選択するには、
core-file
コマンドやexec-file
コマンドを使用します
(ファイルを指定するコマンドを参照)。
既に実行中のプロセスをターゲットとして指定するには、
attach
コマンドを使用します
(既に実行中のプロセスのデバッグを参照)。
target type parameters
target
コマンド実行後RETキーを押しても、
target
コマンドは再実行されません。
help target
info target
コマンドかinfo files
コマンドを使用します
(ファイルを指定するコマンドを参照)。
help target name
set gnutarget args
set gnutarget
コマンドを使用して、
ファイルのフォーマットを指定することもできます。
ほとんどのtarget
コマンドとは異なり、
gnutarget
におけるtarget
はマシンではなくプログラムです。
注意:set gnutarget
でファイル・フォーマットを指定するには、
実際のBFD名を知っている必要があります。
ファイルを指定するコマンドを参照してください。
show gnutarget
gnutarget
がどのようなファイル・フォーマットを読むよう設定されているかを表示させるには、
show gnutarget
コマンドを使用します。
gnutarget
を設定していない場合、
個々のファイルのフォーマットをGDBが自動的に決定します。
この場合、
show gnutarget
を実行するとThe current BDF target is "auto"
と表示されます。
以下に一般的なターゲットをいくつか示します (GDBの設定により、 利用可能であったり利用不可であったりします)。
target exec program
target core filename
target remote dev
target remote
はload
コマンドもサポートしています。
これは、
スタブをターゲット・システムに持っていく方法が別にあり、
かつ、
ダウンロードによって破壊されないようなメモリ上の位置にそれを置くことができる場合にのみ役に立ちます。
target sim
target udi keyword
target amd-eb dev speed PROG
target remote
の場合と同様、
devはシリアル装置です。
speedによって回線速度を指定することができます。
PROGは、
デバッグ対象となるプログラムをPC 上の DOS から見た場合の名前です。
AMD29KのEBMONプロトコルを参照してください。
target hms dev
device
とspeed
によって使用されるシリアル回線と通信速度を制御します。
GDBと日立のマイクロ・プロセッサを参照してください。
target nindy devicename
target st2000 dev speed
target vxworks machinename
target bug dev
target cpu32bug dev
target op50n dev
target w89k dev
target est dev
target rom68k dev
target array dev
target sparclite dev
target remote dev
です。
GDBの設定が異なれば、 利用可能なターゲットも異なるものになります。 ユーザの設定によって、 ターゲットの数は多くなったり少なくなったりします。
ターゲット・システム上で使用するバイト・オーダーを選択することができます。
set endian big
コマンドもしくはset endian little
コマンドを使用します。
実行ファイルに関連付けられているバイト・オーダーを使用するようGDBに指示するには、
set endian auto
コマンドを使用します。
show endian
コマンドによって、
カレントなバイト・オーダーの設定を表示させることができます。
注意: 現在のところ、 組み込みのMIPSの設定だけが、 ターゲットのバイト・オーダーの動的な選択をサポートしています。
通常の方法でGDBを実行させることのできないマシン上で実行中のプログラムをデバッグするには、 リモート・デバッグ機能を使うのが便利です。 例えば、 オペレーティング・システムのカーネルのデバッグや、 フル機能を持つデバッガを実行するのに十分な機能を持つ汎用的なオペレーティング・システムを持たないような小規模なシステムでのデバッグでは、 ユーザはリモート・デバッグ機能を使うことになるかもしれません。
GDBはその設定によっては、 特別なシリアル・インターフェイスやTCP/IPインターフェイスを持ち、 これを特定のデバッグ・ターゲット用に使用することができます。 さらに、 GDBには汎用的なシリアル・プロトコルが組み込まれており (GDBに特有のもので、 特定のターゲット・システムに特有なものではありません)、 リモート・スタブを書けばこれを使用することができます。 リモート・スタブとは、 GDBと通信するためにリモート・システム上で動作するコードです。
GDBの設定によっては、
他のリモート・ターゲットが利用可能な場合もあります。
利用可能なリモート・ターゲットを一覧表示させるには、
help target
コマンドを使用します。
他のマシン上で実行中のプログラムをデバッグするには (targetマシンをデバッグするには)、 そのプログラムが単独で実行できるようにするために必要な通常の事前条件をすべて整える必要があります。 例えば、 Cのプログラムの場合、
次に、ユーザ・プログラムがシリアル・ポートを使って、GDBを実行中のマシン (ホスト・マシン) と通信できるように準備します。 一般的には、以下のような形になります。
gdbserver
という補助プログラムを使うこともできます。
詳細については、
gdbserver
プログラムの使用を参照してください。
デバッグ・スタブはリモート・マシンのアーキテクチャに固有のものです。 例えば、 SPARCボード上のプログラムをデバッグするには`sparc-stub.c'を使います。
以下に実際に使えるスタブを列挙します。 これらは、 GDBと一緒に配布されています。
i386-stub.c
m68k-stub.c
sh-stub.c
sparc-stub.c
sparcl-stub.c
GDBとともに配布されるREADMEファイルには、 新しく追加された他のスタブのことが記されているかもしれません。
各ユーザのアーキテクチャ用のデバッグ・スタブは、 3つのサブルーチンを提供します。
set_debug_traps
handle_exception
が実行されるよう設定します。
ユーザ・プログラムは、
その先頭近くでこのサブルーチンを明示的に呼ばなければなりません。
handle_exception
handle_exception
が実行されるよう設定されます。
ユーザ・プログラムが実行中に
(例えば、ブレイクポイントで)
停止すると、
handle_exception
が制御権を獲得し、
ホスト・マシン上のGDBとの通信を行います。
これが、
通信プロトコルが実装されている部分です。
handle_exception
はターゲット・マシン上でGDBの代理として機能します。
それはまず、
ユーザ・プログラムの状態に関する情報を要約して送ることから始めます。
次に、
処理を継続して、
GDBが必要とする情報を入手し転送します。
これは、
ユーザがユーザ・プログラムの実行を再開させるようなGDBコマンドを実行するまで続きます。
そのようなコマンドが実行されると、
handle_exception
は制御をターゲット・マシン上のユーザ・コードに戻します。
breakpoint
handle_exception
に、
つまり事実上GDBに渡されます。
マシンによっては、
シリアル・ポートから文字を受け取るだけでトラップが発生することもあります。
このような場合には、
ユーザ・プログラム自身からbreakpoint
を呼び出す必要はなく、
ホストのGDBセッションから`target remote'を実行するだけで制御を得ることができます。
これらのどのケースにも該当しない場合、
あるいは、
デバッグ・セッションの開始箇所としてあらかじめ定義されたところでユーザ・プログラムが停止することを単に確実にしたいのであれば、
breakpoint
を呼び出してください。
GDBとともに配布されるデバッグ用スタブは特定のチップのアーキテクチャ用にセットアップされたものですが、 デバッグのターゲット・マシンのそれ以外の部分に関する情報は持っていません。
まず最初に、 どのようにしてシリアル・ポートと通信するかをスタブに教えてやる必要があります。
int getDebugChar()
getchar
と同一かもしれません。
これら2つを区別したい場合を考慮して、
異なる名前が使われています。
void putDebugChar(int)
putchar
と同一かもしれません。
これら2つを区別したい場合を考慮して、
異なる名前が使われています。
実行中のユーザ・プログラムをGDBが停止できるようにしたいのであれば、
割り込み駆動型のシリアル・ドライバを使用して、
^C
(control-C文字、
あるいは`\003')
を受信した時に停止するよう設定する必要があります。
GDBはこの文字を使って、
リモート・システムに対して停止するよう通知します。
デバッグ・ターゲットが適切なステータス情報をGDBに対して返せるようにするためには、
おそらく標準のスタブを変更する必要があるでしょう。
最も美しくなく、
しかし最も迅速にこれを実現する方法は、
ブレイクポイント命令を実行することです
(この方法が「美しくない」のは、
GDBがSIGINT
ではなくSIGTRAP
を発生させる点にあります)。
ユーザが提供する必要のある他のルーチンには、 以下のようなものがあります。
void exceptionHandler (int exception_number, void *exception_address)
exceptionHandler
の助けを借りなくても自分で割り込みをマスクすることができます。
void flush_i_cache()
また、次のライブラリ・ルーチンが使用可能であることを確かめなければなりません。
void *memset(void *, int, int)
memset
です。
フリーのlibc.a
を持っていれば、
そこにmemset
があります。
フリーのlibc.a
がなければ、
memset
をハードウェアの供給元から入手するか、自分で書く必要があります。
GNU Cコンパイラを使っていないのであれば、
他の標準ライブラリ・サブルーチンも必要になるかもしれません。
これは、
スタブによって異なりますが、
一般的に言ってスタブは、
gcc
がインライン・コードとして生成する共通ライブラリ・サブルーチンのいくつかを使用する可能性があります。
要約すると、ユーザ・プログラムがデバッグできるようになると、以下の手順に従わなければなりません。
getDebugChar
,putDebugChar
,flush_i_cache
,memset
,exceptionHandler
.
set_debug_traps(); breakpoint();
exceptionHook
という変数を提供する必要があります。
通常は、
以下のように使います。
void (*exceptionHook)() = 0;
set_debug_traps
が呼ばれる前に、
ユーザがこの変数をユーザ・プログラム内のある関数を指すよう設定すると、
トラップ
(例えば、
バス・エラー)
で停止した後にGDBが処理を継続実行する時に、
その関数が呼び出されます。
exceptionHook
によって指される関数は1つの引数付きで呼び出されます。
それはintint
型の例外番号です。
target remote
コマンドを使って通信を確立します。
引数には、
シリアル回線に接続された装置名あるいは
(通常はターゲットとの間にシリアル回線を持つ端末サーバの)
TCPポートを指定することで、
どのようにしてターゲット・マシンと通信するかを指定します。
例えば、
`/dev/ttyb'という名前の装置に接続されているシリアル回線を使うには、
target remote /dev/ttybとします。 TCP コネクションを使うには、
host:port
という形式の引数を使用します。
例えば、
manyfarms
という名前の端末サーバのポート2828に接続するには、
target remote manyfarms:2828とします。
ここまでくると、 データの値の調査、 変更、 リモート・プログラムのステップ実行、 継続実行に通常使用するすべてのコマンドを使用することができます。
リモート・プログラムの実行を再開し、
そのデバッグを止めるにはdetach
コマンドを使います。
GDBがリモート・プログラムを待っている時にはいつでも、 割り込み文字 (多くの場合 C-C) を入力すると、 GDBはそのプログラムを停止しようとします。 これは成功することも失敗することもありますが、 その成否は、 リモート・システムのハードウェアやシリアル・ドライバにも依存します。 割り込み文字を再度入力すると、 GDBは以下のプロンプトを表示します。
Interrupted while waiting for the program. Give up (and stop debugging it)? (y or n)
ここでyを入力すると、 GDBはリモート・デバッグ・セッションを破棄します (後になって再実行したくなった場合には、 接続するために`target remote'を再度使用します)。 nを入力すると、 GDBは再び待ち状態になります。
GDBとともに提供されるスタブ・ファイルはターゲット側の通信プロトコルを実装します。 そしてGDB側の通信プロトコルは、 GDBのソース・ファイル`remote.c'に実装されています。 通常ユーザは、 これらのサブルーチンに通信処理を任せて、 詳細を無視することができます (ユーザが独自のスタブ・ファイルを作成する時でも詳細を無視して、 既存のスタブ・ファイルを元にして始めることができます。 `sparc-stub.c'が最もよく整理されており、 したがって最も読みやすくなっています)。
しかし、 場合によっては、 プロトコルについて何かを知る必要が出てくることもあるでしょう。 例えば、 ターゲット・マシンに1つしかシリアル・ポートがなく、 ユーザ・プログラムがGDB宛のパケットを検出した時に何か特別なことをするようにしたい場合です。
(単一文字による確認メッセージを除く) すべてのGDBコマンドとそれに対する応答は、 チェックサムを含むパケットとして送信されます。 パケットは、 文字`$'で始まり、 文字`#'に2桁のチェックサム値が続いて終ります。
$packet info#checksum
ここで、 checksumはpacket infoのすべての文字の値を合計したものを256で割った余りとして計算されます。
ホスト・マシンもしくはターゲット・マシンがパケットを受信した時、最初に期待される応答は確認メッセージです。 これは単一文字で、 (パッケージが正しく受信されたことを示す) `+'もしくは (再送要求を示す) `-'です。
ホスト (GDB) がコマンドを送信し、 ターゲット (ユーザ・プログラムに組み込まれたデバッグ・スタブ) が応答としてデータを送信します。 ターゲットは、ユーザ・プログラムが停止した時にも、データを送信します。
コマンド・パケットは最初の文字で区別されます。 最初の文字がコマンドの種類を表します。
以下に、 現在サポートされているコマンドをいくつか列挙します (コマンドの完全なリストについては`gdb/remote.c'を参照)。
g
G
maddr,count
Maddr,count:...
c
caddr
s
saddr
k
?
T
シリアル接続に問題がある場合には、
set remotedebug
コマンドを使うことができます。
これにより、
GDBはシリアル回線経由でリモート・マシンとの間で送受信したすべてのパケットを報告するようになります。
パケット・デバッグ用の情報はGDBの標準出力ストリームに表示されます。
set remotedebug off
によってこの設定が解除され、
show remotedebug
によって現在の設定が表示されます。
gdbserver
プログラムの使用
gdbserver
はUNIX系のシステム用の制御プログラムで、
これにより、
通常のデバッグ用スタブをリンクすることなく、
target remote
コマンドによって、
ユーザ・プログラムをリモートのGDBに接続することができます。
gdbserver
はデバッグ用スタブに完全に取って代わるものではありません。
というのは、
gdbserver
はGDBが必要とするのと同様のオペレーティング・システムの機能を基本的には必要とするからです。
実際、
リモートのGDBと接続するためにgdbserver
を実行できるシステムであれば、
GDBをローカルに実行することも可能です。
それでも、
gdbserver
はGDBと比較するとずっとサイズが小さいので、
便利なことがあります。
また、
gdbserver
の移植はGDB全体の移植よりも簡単なので、
gdbserver
を使うことで、
新しいシステムでの作業をより早く開始することができます、
最後に、
リアル・タイム・システムの開発をしている場合、
リアル・タイムな操作に関わるトレードオフのために、
例えばクロス・コンパイルなどによって他のシステム上で可能な限り多くの開発作業を行ったほうがより便利であるということがあるでしょう。
デバッグ作業に関しても、
gdbserver
を使うことで同様の選択を行うことができます。
GDBとgdbserver
はシリアル回線もしくはTCP接続を介して、
標準的なGDBリモート・シリアル・プロトコルによって通信します。
gdbserver
はユーザ・プログラムのシンボル・テーブルを必要とはしませんので、
スペースの節約が必要であれば、
プログラムをストリップすることができます。
ホスト・システム上のGDBがシンボルに関するすべての処理を実行します。
サーバを使うには、GDBとの通信方法、
ユーザ・プログラムの名前、
ユーザ・プログラムへの引数を教えてやる必要があります。
構文は、
以下のとおりです。
target> gdbserver comm program [ args ... ]commは (シリアル回線を使うための) 装置名か、 もしくは、 TCPのホスト名とポート番号です。 例えば、 `foo.txt'という引数でEmacsをデバッグし、 シリアル・ポート`/dev/com1'経由でGDBと通信するには、 以下のように実行します。
target> gdbserver /dev/com1 emacs foo.txt
gdbserver
は、
ホスト側のGDBが通信してくるのを受動的に待ちます。
シリアル回線の代わりにTCP接続を使うには、
以下のようにします。
target> gdbserver host:2345 emacs foo.txt前の例との唯一の違いは第1引数です。 これは、 ホストのGDBと TCP によって接続することを指定しています。 `host:2345'は
gdbserver
がマシン`host'からローカルのTCPポート2345へのTCP接続を期待していることを意味します
(現在のバージョンでは、
`host'の部分は無視されます)。
ターゲット・システム上で既に使われている TCP ポートでなければ、任意の番号をポート番号として選択できます
(例えば、
23
はtelnet
に予約されています)
(4)。
ここで指定したのと同じポート番号を、
GDBのtarget remote
コマンドで使わなければなりません。
target remote
コマンドによってgdbserver
との通信を確立します。
引数には、
装置名
(通常は`/dev/ttyb'のようなシリアル装置)
もしくはhost:PORT
という形式でのTCPポート記述子を指定します。
例えば、
(gdb) target remote /dev/ttybでは、 シリアル回線`/dev/ttyb'を介してサーバと通信しますし、
(gdb) target remote the-target:2345では、 ホスト`the-target'上のポート2345に対するTCP接続によってサーバと通信します。 TCP接続を使う場合には、
target remote
コマンドを実行する前にgdbserver
を起動しておかなければなりません。
そうしないと、エラーになります。
エラー・テキストの内容はホスト・システムによって異なりますが、
通常は`Connection refused'のような内容です。
gdbserve.nlm
プログラムの使用
gdbserve.nlm
はNetWareシステムでの制御プログラムであり、
これによりtarget remote
コマンドでユーザ・プログラムをリモートのGDBに接続することができます。
GDBとgdbserve.nlm
は標準のGDBリモート・シリアル・プロトコルを使って、
シリアル回線経由で通信します。
gdbserve.nlm
はユーザ・プログラムのシンボル・テーブルを必要とはしませんので、
スペースの節約が必要であれば、
プログラムをストリップすることができます。
ホスト・システム上のGDBがシンボルに関わるすべての処理を実行します。
サーバを使うには、
GDBとの通信方法、
ユーザ・プログラムの名前、
ユーザ・プログラムの引数を教えてやる必要があります。
構文は、
以下のとおりです。
load gdbserve [ BOARD=board ] [ PORT=port ] [ BAUD=baud ] program [ args ... ]boardとportがシリアル回線を指定します。 baudは接続に使われるボーレートを指定します。 portとnodeのデフォルト値は0、 baudのデフォルト値は9600 bpsです。 例えば、 `foo.txt'という引数でEmacsをデバッグし、 シリアル・ポート番号2、 ボード1経由で19200 bpsの接続でGDBと通信するには、 以下のように実行します。
load gdbserve BOARD=1 PORT=2 BAUD=19200 emacs foo.txt
target remote
コマンドによって
gdbserve.nlm
との通信を確立します。
引数には、
装置名
(通常は`/dev/ttyb'のようなシリアル装置)
を指定します。
例えば、
(gdb) target remote /dev/ttybは、 シリアル回線`/dev/ttyb'を介してサーバと通信します。
NindyはIntel 960ターゲット・システム用のROM Monitorプログラムです。 Nindyを使ってリモートのIntel 960を制御するようGDBが設定されている場合、 いくつかの方法によってGDBに960との接続方法を教えることができます。
target
コマンドを使う方法
(ターゲットを管理するコマンドを参照してください)
コマンドライン・オプションを一切使わずにgdb
を起動すると、
通常のGDBプロンプトが表示される前に、
どのシリアル・ポートを使うのかを入力するよう促されます。
Attach /dev/ttyNN -- specify NN, or "quit" to quit:
このプロンプトに対して使いたいシリアル・ポートを示すサフィックスを
(`/dev/tty'に続けて)
入力します。
もしそうしたいのであれば、
プロンプトに空行で答えることによって、
Nindyとの接続を確立せずに起動することもできます。
この場合、
後にNindyと接続したい時にはtarget
コマンドを使います
(ターゲットを管理するコマンドを参照)。
接続されたNindy-960とのGDBセッションを開始するためのオプションを以下に示します。
-r port
tty
固有の一意なサフィックス
(例:`-r a')
のいずれによっても指定することができます。
GDB
port
-O
注意:`-O'を指定したにもかかわらず、 実際にはより新しいプロトコルを期待しているターゲット・システムに接続しようとした場合、 あたかも通信速度の不一致によって接続が失敗したかのように見えます。 GDBは異なる回線速度によって再接続を繰り返し試みます。 割り込みによって、この処理を中断することができます。
-brk
BREAK
信号を送信するようGDBに対して指定します。
注意:多くのターゲット・システムは、 このオプションが必要とするハードウェアを備えていません。 このオプションは、 2、 3のボードでしか機能しません。
標準の`-b'オプションによってシリアル・ポート上で使用される回線速度を制御します。
reset
GDBは、
a29kプロセッサ・ファミリをデバッグするためのAMD UDI
(Universal Debugger Interface)
プロトコルをサポートします。
MiniMONモニタを実行するAMDターゲットでこの設定を使うには、
AMD社から無料で入手可能なMONTIP
プログラムが必要になります。
また、
AMD社から入手可能なUDI準拠のa29kシミュレータ・プログラムISSTIP
とともにGDBを使うこともできます。
target udi keyword
AMD社はPC組み込み用の29K開発ボードを、
DOS上で動作するEBMON
というモニタ・プログラムと一緒に配布しています。
この開発システムは、
省略してEB29Kと呼ばれます。
UNIXシステム上のGDBを使って、
EB29Kボード上でプログラムを実行するには、
まず
(EB29Kを組み込んだ)
PCとUNIXシステムのシリアル・ポートの間をシリアル回線で接続しなければなりません。
以下の節では、
PCの`COM1'ポートとUNIXシステムの`/dev/ttya'との間をケーブルで接続してあるものと仮定します。
次に、 PC上のDOSで以下のようなことを行うことによって、 PCのポートをセットアップします。
C:\> MODE com1:9600,n,8,1,none
MS DOS 4.0上で実行されているこの例では、 通信速度を9600 bps、 パリティ・ビットなし、 データ・ビットを8ビット、 ストップ・ビットを1ビット、 リトライなしに設定しています。 UNIX側を設定する際には、 同一の通信パラメータを使わなければなりません。
シリアル回線のUNIX側にPCの制御権を与えるには、 DOSコンソール上で以下のように実行します。
C:\> CTTY com1
(後に、
DOSコンソールに制御を戻したい時には、
CTTY con
コマンドを使うことができます
---ただし、
制御権を持っている装置から、
ここでの例では`COM1'に接続されているシリアル回線を通して、
このコマンドを送信する必要があります)。
UNIXのホストからは、
PCと通信するのにtip
やcu
のような通信プログラムを使います。
例えば、
cu -s 9600 -l /dev/ttya
ここで示されているcu
オプションはそれぞれ、
使用する回線速度とシリアル・ポートを指定しています。
tip
コマンドを使った場合は、
コマンドラインは以下のようなものになるでしょう。
tip -9600 /dev/ttya
ここでtip
への引数として指定した`/dev/ttya'の部分には、
ユーザのシステムでは異なる名前を指定する必要があるかもしれません。
使用するポートを含む通信パラメータは、
"remote"記述ファイルにおいてtip
コマンドへの引数と関連付けられます。
通常このファイルは、
システム・テーブル`/etc/remote'です。
tip
接続、
もしくはcu
接続を使用して、
DOSの作業ディレクトリをユーザの
29Kプログラムがあるディレクトリに変更し、
PCプログラムEBMON
(AMD社からボードとともに提供されるEB29K制御プログラム)
を起動します。
以下に示すのによく似た、
EBMON
プロンプト`#'で終わるEBMON
の初期画面が表示される筈です。
C:\> G: G:\> CD \usr\joe\work29k G:\USR\JOE\WORK29K> EBMON Am29000 PC Coprocessor Board Monitor, version 3.0-18 Copyright 1990 Advanced Micro Devices, Inc. Written by Gibbons and Associates, Inc. Enter '?' or 'H' for help PC Coprocessor Type = EB29K I/O Base = 0x208 Memory Base = 0xd0000 Data Memory Size = 2048KB Available I-RAM Range = 0x8000 to 0x1fffff Available D-RAM Range = 0x80002000 to 0x801fffff PageSize = 0x400 Register Stack Size = 0x800 Memory Stack Size = 0x1800 CPU PRL = 0x3 Am29027 Available = No Byte Write Available = Yes # ~.
続いて、
cu
プログラムもしくはtip
プログラムを終了させます
(上の例では、
EBMON
プロンプトにおいて~.
を入力することで終了させています)。
EBMON
は、
GDBが制御権を獲得できる状態で、
実行を継続します。
この例では、
PCとUNIXシステム上に同一の29Kプログラムが確実に存在するようにするのに、
恐らく最も便利な方法を使うことを仮定しました。
それは、
PC/NFSによる接続で、
UNIXホストのファイル・システムの1つをPCのG:
ドライブとする方法です。
PC/NFSもしくは、
2つのシステム間を接続する類似の方法がない場合、
フロッピ・ディスクによる転送など、
UNIXシステムからPCへ29Kプログラムを転送するための他の手段を準備する必要があります。
GDBはシリアル回線経由でそれをダウンロードすることはしません。
最後に、
cd
でUNIXシステム上で29Kプログラムが存在するディレクトリに移動し、
29Kプログラムの名前を引数に指定してGDBを起動します。
cd /usr/joe/work29k gdb myfoo
これでtarget
コマンドが使えるようになります。
target amd-eb /dev/ttya 9600 MYFOO
この例では、
ユーザ・プログラムは`myfoo'と呼ばれるファイルにあるものと仮定しています。
target amd-eb
に対して最後の引数として指定するファイル名は、
DOS上でのプログラム名でなければならない点に注意してください。
この例では単にMYFOO
となっていますが、
DOSのパス名を含むこともできますし、
転送メカニズムによっては、
UNIX側での名前とは似ても似つかないものになるかもしれません。
ここまでくると、
好きなようにブレイクポイントを設定することができます。
29Kボード上でのプログラムの実行を監視する準備が整えば、
GDBのrun
コマンドを使います。
リモート・プログラムのデバッグを停止するには、
GDBのdetach
コマンドを使います。
PC の制御を PC コンソールに戻すには、GDBセッションが終了した後に、EBMON
EBMON
にアタッチするために、
もう一度tip
もしくはcu
を使います。
その後、
q
コマンドによってEBMON
をシャットダウンし、
DOSのコマンドライン・インタープリタに制御を戻します。
CTTY con
と入力して、
入力されたコマンドがメインのDOSコンソールによって受け取られるようにし、
~.を入力してtip
もしくはcu
を終了させます。
target amd-eb
コマンドは、
接続に関わる問題のデバッグを支援するため、
カレントな作業ディレクトリに`eb.log'というファイルを作成します。
`eb.log'は、
EBMON
に送信されたコマンドのエコーを含む、
EBMON
からのすべての出力を記録します。
別のウィンドウ内でこのファイルに対して`tail -f'を実行すると、
EBMON
に関わる問題やPC側での予期せぬイベントを理解する助けになることがよくあります。
ST2000をホスト・システムに接続する方法については、 製造元のマニュアルを参照してください。 ST2000が物理的に接続されれば、 それをデバッグ環境として確立するには、以下を実行します。
target st2000 dev speed
ここで、
devは通常、
シリアル回線によってST2000と接続される`/dev/ttya'のようなシリアル装置の名前です。
代わりに、
hostname:portnumber
という構文を使って
(例えば、端末多重化装置経由で接続されたシリアル回線への)
TCP接続としてdevを指定することもできます。
このターゲットに対して、
load
コマンドとattach
コマンドは定義されていません。
普段スタンドアロンで操作しているのと同様に、
ST2000にユーザ・プログラムをロードしなければなりません。
GDBは
(シンボルのような)
デバッグ用の情報を、
ホスト・コンピュータ上にある別のデバッグ・バージョンのプログラムから読みとります。
ST2000での作業を支援するため、 以下の補助的なGDBコマンドが利用可能になっています。
st2000 command
connect
GDBを使用することで、
UNIXのホストから、
ネットワークに接続されたVxWorks端末上でタスクを起動しデバッグすることができます。
VxWorksシェルから起動され、
既に実行中の状態のタスクもデバッグできます。
GDBはUNIXホスト上で実行されるコードとVxWorksターゲット上で実行されるコードの両方を使います。
gdb
プログラムはUNIXホスト上にインストールされ実行されます
(ホスト上のプログラムをデバッグするのに使うGDBと区別するために、
vxgdb
という名前でインストールされることもあります)。
VxWorks-timeout args
vxworks-timeout
オプションをサポートしています。
このオプションはユーザによってセットされるもので、
argsはGDBがRPCの応答を待つ秒数を表します。
実際のVxWorksターゲットが速度の遅いソフトウェア・シミュレータであったり、
帯域の小さいネットワーク回線を介して遠距離にある場合などに使うとよいでしょう。
以下に示すVxWorksとの接続に関する情報は、 このマニュアルの製作時における最新の情報です。 新しくリリースされたVxWorksでは、異なる手順を使うかもしれません。
GDBをVxWorksで使うためには、
VxWorksカーネルを再構築して、
VxWorksライブラリ`rdb.a'の中にリモート・デバッグ用のインターフェイス・ルーチンを組み込む必要があります。
そのためには、
VxWorksのコンフィギュレーション・ファイル`configAll.h'の中でINCLUDE_RDB
を定義して、
VxWorksカーネルを再構築します。
この結果として生成されるカーネルには`rdb.a'が含まれ、
VxWorksの起動時にソース・デバッグ用のタスクtRdbTask
が起動されます。
VxWorksの設定や再構築に関する詳細については、
製造元のマニュアルを参照してください。
VxWorksシステムへの`rdb.a'の組み込みが終わり、
UNIXの実行モジュール検索パスにGDBの存在するパスを加えれば、
GDBを実行するための準備は完了です。
UNIXホストからgdb
(インストールの方法によってはvxgdb
)
を実行します。
GDBが起動し、以下のプロンプトを表示します。
(vxgdb)
GDBのtarget
コマンドによって、
ネットワーク上のVxWorksターゲットに接続します。
tt
というホスト名を持つターゲットに接続するには、
以下のようにします。
(vxgdb) target vxworks tt
GDBは以下のようなメッセージを表示します。
Attaching remote machine across net... Connected to tt.
続いてGDBは、 最後にVxWorksターゲットが起動された時点以降にロードされたオブジェクト・モジュールのシンボル・テーブルを読み込もうと試みます。 GDBはこれらのファイルを、 コマンドの検索パスにリストされているディレクトリを検索することで見つけます (ユーザ・プログラムの環境を参照)。 オブジェクト・ファイルを見つけることができない場合には、 以下のようなメッセージを表示します。
prog.o: No such file or directory.
このような場合には、
GDBのpath
コマンドによって適切なディレクトリを検索パスに加え、
再度target
コマンドを実行します。
VxWorksターゲットに接続済みで、
まだロードされていないオブジェクトをデバッグしたい場合には、
GDBのload
コマンドを使ってUNIXからVxWorksへ追加的にファイルをダウンロードすることができます。
load
コマンドの引数として指定されたオブジェクト・ファイルは、
実際には2回オープンされます。
まず、
コードをダウンロードするためにVxWorksターゲットによってオープンされ、
次にシンボル・テーブルを読み込むためにGDBによってオープンされます。
2つのシステム上のカレントな作業ディレクトリが異なると、
これは問題を引きおこします。
両方のシステムが同一のファイル・システムをNFSマウントしているのであれば、
絶対パスを使うことで問題を回避することができます。
これ以外の場合は、
両方のシステムで作業ディレクトリをオブジェクト・ファイルが存在するディレクトリに設定し、
パスを一切使わずにその名前だけでファイルを参照するのが、
最も簡単でしょう。
例えば、プログラム
`prog.o'がVxWorksでは`vxpath/vw/demo/rdb'に存在し、
ホストでは`hostpath/vw/demo/rdb'に存在するとしましょう。
このプログラムをロードするには、
VxWorks上で以下を実行します。
-> cd "vxpath/vw/demo/rdb"
次にGDB上で、 以下を実行します。
(vxgdb) cd hostpath/vw/demo/rdb (vxgdb) load prog.o
GDBは次のような応答を表示します。
Reading symbol data from wherever/vw/demo/rdb/prog.o... done.
ソース・ファイルを編集し再コンパイルした後、
load
コマンドを使ってオブジェクト・モジュールを再ロードすることもできます。
ただし、
これを行うと、
GDBはその時点で定義されているすべてのブレイクポイント、
自動表示設定、
コンビニエンス変数を削除し、
値ヒストリを初期化してしまいますので、
注意してください
(これは、
ターゲット・システムのシンボル・テーブルを参照するデバッガのデータ構造の完全性を保つために必要です)。
以下のようにattach
コマンドを使うことで、
既存のタスクにアタッチすることも可能です。
(vxgdb) attach task
ここでtaskはVxWorksの16進数のタスクIDです。 アタッチする時に、 タスクは実行中であってもサスペンドされていても構いません。 実行中であったタスクは、 アタッチされた時点でサスペンドされます。
開発者は GDB を使うことにより、
Sparclet ターゲット上で実行中のタスクを Unix ホストからデバッグできるようになります。
GDB は、
Unix ホスト上でも Sparclet ターゲット上でも動作するコードを使用します。
gdb
プログラムは Unix ホスト上にインストールされ実行されます。
timeout args
remotetimeout
をサポートするようになりました。
このオプションはユーザによって設定されるもので、
args は GDB が応答を待つ秒数を表します。
デバッグ用にコンパイルする際には、 デバッグ情報を得るために "-g" オプションを、 また、 ターゲット上でロードしたい位置にプログラムを再配置するために "-Ttext" オプションを指定します。 セクションのサイズを縮小するために "-n"、 もしくは、 "-N" オプションを加えるのも良いでしょう。
sparclet-aout-gcc prog.c -Ttext 0x12010000 -g -o prog -N
アドレスが意図したものと一致しているかどうかを検証するのに objdump を使うことができます。
sparclet-aout-objdump --headers --syms prog
GDB を見つけるための Unix 実行サーチ・パスを設定すれば、
GDB を実行するための準備は完了です。
Unix ホストから gdb
(インストールの方法によっては、
sparclet-aout-gdb
)
を実行します。
GDB が起動されて、 プロンプトを表示します。
(gdbslet)
GDB の file
コマンドによってデバッグするプログラムを選択することができます。
(gdbslet) file prog
このコマンドを実行すると、 GDB は `prog' のシンボル・テーブルを読み込もうとします。 GDB は、 コマンド・サーチ・パスに含まれるディレクトリを探索することによって、 そのファイルを見つけます。 そのファイルがデバッグ情報付き (オプション "-g") でコンパイルされた場合、 ソース・ファイルも探されます。 GDB は、 ディレクトリ・サーチ・パス (ユーザ・プログラムの環境を参照) に含まれるディレクトリを探索することによって、 そのソース・ファイルを見つけます。 ファイルが見つからない場合には、 次のようなメッセージを表示します。
prog: No such file or directory.
このメッセージが表示された場合には、
GDB の path
コマンドと dir
コマンドを使って適切なディレクトリをサーチ・パスに加えてから、
target
コマンドを再実行します。
GDB の target
コマンドによって Sparclet ターゲットへ接続することができます。
シリアル・ポート "ttya
" でターゲットに接続するには、
以下のように入力します。
(gdbslet) target sparclet /dev/ttya Remote target sparclet connected to /dev/ttya main () at ../prog.c:3
GDB は以下のようなメッセージを表示します。
Connected to ttya.
Sparclet ターゲットへの接続が完了すると、
GDB の load
コマンドを使って、
ホストからターゲットへファイルをダウンロードすることができます。
ファイル名とロード・オフセットは、
load
コマンドへの引数として渡さなければなりません。
ファイル形式は aout ですので、
プログラムはその開始アドレスにロードされなければなりません。
開始アドレスの値を知るには objdump を使うことができます。
ロード・オフセットとは、
ファイルの個々のセクションの VMA(仮想メモリ・アドレス)に加算されるオフセットのことです。
例えば、
プログラム `prog' が、
text セクションのアドレス 0x12010000、
data セクションのアドレス 0x12010160、
bss セクションのアドレス 0x12010170 としてリンクされているとすると、
GDB では以下のように入力します。
(gdbslet) load prog 0x12010000 Loading section .text, size 0xdb0 vma 0x12010000
プログラムがリンクされたアドレスとは異なるアドレスにコードがロードされた場合、
どこにシンボル・テーブルをマップするかを GDB に通知するために section
コマンドと add-symbol-file
コマンドを使う必要があるかもしれません。
以上により、
GDB の実行制御コマンド b
、
step
、
run
等を使ってタスクのデバッグを開始することができます。
コマンドの一覧については、
GDB マニュアルを参照してください。
(gdbslet) b main Breakpoint 1 at 0x12010000: file prog.c, line 3. (gdbslet) run Starting program: prog Breakpoint 1, main (argc=1, argv=0xeffff21c) at prog.c:3 3 char *symarg = 0; (gdbslet) step 4 char *execarg = "hello!"; (gdbslet)
日立のSH、 H8/300、 H8/500と通信するためには、 GDBは以下の情報を知っている必要があります。
シリアル装置を明示的に指定する必要があるのであれば、
そのために特別にあるgdb
の`device port'コマンドを使用します。
portのデフォルトは、
ホスト上で最初に利用可能なポートです。
これはUNIXホスト上でのみ必要であり、
そこでは典型的には`/dev/ttya'という名前になります。
gdb
には通信速度を設定するための特別なコマンド`speed bps'があります。
このコマンドもまた
UNIXホストからのみ使用されるものです。
DOSホストでは通常どおり、
GDBからではなくDOSのmodeコマンドによって回線速度を設定します
(例えば、
9600 bpsの接続を確立するには`mode com2:9600,n,8,1,p'のように実行します)。
`device'コマンドと`speed'コマンドは、
日立マイクロ・プロセッサ・プログラムのデバッグにUNIXホストを使う場合のみ利用可能です。
DOSホストを使う場合、
GDBは、
PCシリアル・ポート経由で開発ボードと通信するのに
asynctsr
と呼ばれる補助的な常駐プログラムに依存します。
DOS側でシリアル・ポートの設定をする場合にも
DOSのmode
コマンドを使わなければなりません。
E7000インサーキット・エミュレータを使って、 日立SHもしくはH8/300H用のコードを開発することができます。 `target e7000'コマンドを以下のいずれかの形式で使って、 GDBをE7000に接続してください。
target e7000 port speed
target e7000 hostname
telnet
を使います。
いくつかのGDBコマンドは、 H8/300もしくはH8/500用に設定された場合にのみ利用可能です。
set machine h8300
set machine h8300h
set memory mod
show memory
small
、
big
、
medium
、
compact
のいずれかです。
GDBは、 MIPSのリモート・デバッグ用のプロトコルを使って、 シリアル回線に接続されたMIPSボードと通信することができます。 これは、 GDBを`--target=mips-idt-ecoff'によって設定すると、 利用することができます。
ターゲット・ボードとの接続を指定するには、 以下のGDBコマンドを使用します。
target mips port
gdb
を起動します。
ボードに接続するには、
`target mips port'コマンドを使用します。
ここで、
portはボードに接続されているシリアル・ポートの名前です。
プログラムがまだボードにダウンロードされていないのであれば、
load
コマンドを使ってダウンロードすることができます。
その後、
通常使用できるすべてのGDBコマンドを使うことができます。
例えば、
以下の手順では、
シリアル・ポートを介してターゲット・ボードに接続し、
デバッガによってprogと呼ばれるプログラムをロードし、
実行します。
host$ gdb prog GDB is free software and ... (gdb) target mips /dev/ttyb (gdb) load prog (gdb) run
target mips hostname:portnumber
target pmon port
target ddb port
target lsi port
GDBは MIPS ターゲットに対して以下の特別なコマンドもサポートしています。
set processor args
show processor
set processor
コマンドを使ってMIPSプロセッサの種類を設定します。
例えば、
set processor r3041
はGDBに対して、
3041チップでのみ有効なCPOレジスタを使うことを通知します。
GDBが使っているMIPSプロセッサの種類を知るにはshow processor
コマンドを使います。
GDBが使っているレジスタを知るにはinfo reg
コマンドを使います。
set mipsfpu double
set mipsfpu single
set mipsfpu none
show mipsfpu
mipsfpu
変数に関する設定を`show mipsfpu'によって問い合わせることができます。
set remotedebug n
show remotedebug
remotedebug
変数を設定することによって、
ボードとの通信に関するいくつかのデバッグ用の情報を見ることができます。
`set remotedebug 1'によって値1
を設定すると、
すべてのパケットが表示されます。
値を2
に設定すると、
すべての文字が表示されます。
いつでも`show remotedebug'によってカレントな値を調べることができます。
set timeout seconds
set retransmit-timeout seconds
show timeout
show retransmit-timeout
set timeout seconds
コマンドで制御することができます。
デフォルトは5秒です。
同様に、
パケットに対する確認
(ACK)
を待っている状態でのタイムアウト時間を、
set retransmit-timeout seconds
コマンドで制御することができます。
デフォルトは3秒です。
それぞれの値をshow timeout
とshow retransmit-timeout
で調べることができます
(どちらのコマンドもGDBが`--target=mips-idt-ecoff'用に設定されている場合のみ使用可能です)。
set timeout
で設定されたタイムアウト時間は、
ユーザ・プログラムが停止するのをGDBが待っている間は適用されません。
この場合には、
GDBは永遠に待ち続けます。
これは、
プログラムが停止するまでにどの程度長く実行を継続するのかを知る方法がないからです。
いくつかの設定においては、 ユーザ・プログラムをデバッグする際にハードウェアCPUの代わりに使えるCPUシミュレータをGDBは持っています。 現在のところシミュレータは、 GDBがZilog Z8000もしくは日立マイクロ・プロセッサをデバッグ・ターゲットとして設定されている場合のみ、 利用可能です。
Z8000系については、 `target sim'によりZ8002 (Z8000のセグメントを持たない変種) もしくはZ8001 (セグメントを持つ変種) をシミュレートします。 シミュレータは、 オブジェクト・コードを調べることで、 どちらのアーキテクチャが適切であるかを認識します。
target sim
このターゲットを指定した後、
ホスト・コンピュータ上のプログラムをデバッグするのと同様の方法で、
シミュレートされたCPU用のプログラムをデバッグすることができます。
新しいプログラムのイメージをロードするには
file
コマンドを使い、
ユーザ・プログラムを実行するにはrun
コマンドを使う、
という具合です。
このデバッグ・ターゲットでは、通常のマシン・レジスタ
(info reg
を参照)
がすべて利用可能であるだけでなく、
特別な名前を持つレジスタとして、
さらに3つの情報を提供します。
cycles
insts
time
これらの変数はGDBの式の中で通例どおりに参照することができます。 例えば、 `b fputc if $cycles>5000'は、 シミュレートされたクロック・ティックが最低5,000回発生した後に停止するような条件付きブレイクポイントを設定します。
set
コマンドによってGDBの操作の仕方を変更することができます。
GDBがデータを表示する方法を変更するコマンドについては、
表示設定を参照。
この章では、
その他の設定について説明します。
GDBは、
プロンプトと呼ばれる文字列を表示することで、
コマンドを受け付ける用意ができたことを示します。
通常、
この文字列は`(gdb)'です。
set prompt
コマンドによってプロンプトの文字列を変更することができます。
例えば、
GDBを使ってGDB自体をデバッグしている時には、
いずれかのGDBセッションのプロンプトを変更して、
どちらのGDBとやりとりしているのか区別できるようにすると便利です。
注: 以前のバージョンとは異なり、
現在のset prompt
はユーザが設定したプロンプトの後に空白を追加しません。
これにより、
ユーザは空白で終わるプロンプト、
空白で終わらないプロンプトのいずれでも設定することができます。
set prompt newprompt
show prompt
GDBは入力コマンドをreadlineインターフェイスによって読み込みます。
このGNUライブラリによって、
ユーザにコマンドライン・インターフェイスを提供するプログラムは、
統一された振舞いをするようになります。
これを使うことの利点としては、
GNU Emacsスタイルもしくはviスタイルによるコマンドのインライン編集、
csh
風のヒストリ代替、
複数のデバッグ・セッションにまたがるコマンド・ヒストリの保存と呼び出しができるようになることが挙げられます。
set
コマンドによって、
GDBにおけるコマンドライン編集の振舞いを制御することができます。
set editing
set editing on
set editing off
show editing
GDBはデバッグ・セッション中にユーザが入力したコマンドを記録しているため、 ユーザは実際に何が実行されたかを確実に知ることができます。 以下のコマンドを使って、 GDBのコマンド・ヒストリ機能を管理します。
set history filename fname
GDBHISTFILE
の値になりますが、
この変数が設定されていない場合には`./.gdb_history'になります。
set history save
set history save on
set history filename
コマンドで指定可能です。
デフォルトでは、
このオプションは使用不可の状態になっています。
set history save off
set history size size
HISTSIZE
の値に設定されますが、
この変数が設定されていない場合は256になります。
ヒストリ展開機能により、 文字!には特別な意味が割り当てられます。
!はC言語において論理否定の演算子でもあるので、
ヒストリ展開機能はデフォルトではオフになっています。
set history expansion on
コマンドによってヒストリ展開を利用できるようにした場合には、
(式の中で論理否定として使う)
!の後に空白かタブを入れることによって、
それが展開されないようにする必要のある場合があります。
ヒストリ展開が有効になっている場合でも、
readlineのヒストリ機能は!=や!(という文字列を置き換えようとはしません。
ヒストリ展開を制御するコマンドには、 以下のようなものがあります。
set history expansion on
set history expansion
set history expansion off
vi
のことをよく知らない人は、
このドキュメントを読むと良いでしょう。
show history
show history filename
show history save
show history size
show history expansion
show history
を実行すると、
4つのパラメータの状態がすべて表示されます。
show commands
show commands n
show commands +
GDBのコマンドは、 大量の情報を画面上に出力することがあります。 大量の情報をすべて読むのを支援するために、 GDBは1ページ分の情報を出力する度に、 出力を停止してユーザからの入力を求めます。 出力を継続したい場合は RETキーを押し、 残りの出力を破棄したい場合はqを入力します。 また、 画面幅の設定によって、 どこで行を折り返すかが決まります。 出力の内容に応じて、 単純に次の行に折り返すのではなく、 読み易いところで折り返すよう試みます。
通常GDBは、
termcapデータベースとTERM
環境変数の値、
さらに、
stty rows
、
stty cols
の設定から画面の大きさを知っています。
この結果が正しくない場合、
set height
コマンドとset width
コマンドで上書きすることができます。
set height lpp
show height
set width cpl
show width
set
コマンドは、
画面の高さをlpp行に、
幅をcpl桁に指定します。
関連するshow
コマンドが、
現在の設定を表示します。
ゼロ行の高さを指定すると、
GDBは出力がどんなに長くても、
出力途中で一時停止することをしません。
これは、
出力先がファイルやエディタのバッファである場合に便利です。
同様に、
`set width 0'によってGDBは行の折り返しを行わなくなります。
いつでもGDBに8進、
10進、
16進の数値を慣例にしたがって入力することができます。
8進数は`0'で始まります。
10進数は`.'で終わります。
16進数は`0x'で始まります。
このどれにも該当しないものは、
デフォルトで10進数として入力されます。
同様に、
数値を表示するときも、
特定のフォーマットが指定されていなければ、
デフォルトで10進数として表示されます。
set radix
コマンドによって、
入力、
出力の両方のデフォルトを変更することができます。
set input-radix base
set radix 012 set radix 10. set radix 0xaは基底を 10 進数に設定します。 一方、 `set radix 10'は、 その時点での基底を (それがどれであれ) 変更しません。
set output-radix base
show input-radix
show output-radix
デフォルトでは、
GDBは内部の動作に関する情報を表示しません。
性能の遅いマシンで実行している場合には、
set verbose
コマンドを使うとよいでしょう。
これにより、
GDBは長い内部処理を実行する時にメッセージを出力することで、
ユーザがGDBはクラッシュしたと勘違いしないようにします。
現在のところ、
set verbose
コマンドによって制御されるメッセージは、
ソース・ファイルのシンボル・テーブルを読み込み中であることを知らせるメッセージです。
ファイルを指定するコマンドのsymbol-file
を参照してください。
set verbose on
set verbose off
show verbose
set verbose
がon、
offのどちらの状態であるかを表示します。
デフォルトでは、 オブジェクト・ファイルのシンボル・テーブルに問題を検出しても、 GDBはメッセージを出力しません。 しかし、 コンパイラをデバッグしているような時には、 このような情報があると便利かもしれません (シンボル・ファイル読み込み時のエラーを参照)。
set complaints limit
show complaints
デフォルトでは、 GDBは慎重に動作し、 特定のコマンドを本当に実行するのか確認するために、 時には馬鹿げているとさえ思えるような質問を多く尋ねてきます。 例えば、 既に実行中のプログラムを実行しようとすると、 次のように質問してきます。
(gdb) run The program being debugged has been started already. Start it from the beginning? (y or n)
ユーザが、 実行したコマンドの結果を何がなんでも見てみたいのであれば、 この「機能」を抑止することができます。
set confirm off
set confirm on
show confirm
ブレイクポイント・コマンド (ブレイクポイント・コマンド・リストを参照) とは別に、 一連のコマンドを一括して実行するために保存する方法を、 GDB は2つ提供しています。 ユーザ定義コマンドとコマンド・ファイルがそれです。
ユーザ定義コマンドとは、
ユーザが一連の GDB コマンドに単一コマンドとしての名前を新たに割り当てたものです。
これは、
define
コマンドによって行われます。
ユーザ・コマンドは、
空白で区切られた引数を最高で10個まで受けとることができます。
引数は、
ユーザ・コマンドの中で $arg0...$arg9 としてアクセスすることができます。
簡単な例を示すと:
define adder print $arg0 + $arg1 + $arg2
このコマンドを実行するには、以下のようにします。
adder 1 2 3
上の例では、
adder
というコマンドを定義しています。
このコマンドは、
3つの引数の合計を表示します。
引数は文字列で代用されますので、
変数を参照することもできますし、
複雑な式を使うこともできます。
また、
下位関数の呼び出しを行うこともできます。
define commandname
define
コマンドに続いて与えられる他の GDB コマンド行から構成されます。
これらのコマンドの末尾は、
end
を含む行によって示されます。
if
else
行が続き、
その後に、
式の評価結果が偽であった場合にのみ実行される一連のコマンドが続きます。
末尾は、
end
を含む行によって示されます。
while
if
と似ています。
評価される式である引数を1つだけとり、
その後に必ず、
実行されるべきコマンドが1行に1つずつ続き、
最後に end
がきます。
コマンドは、
式の評価結果が真である限り、
繰り返し実行されます。
document commandname
help
コマンドによってアクセスできます。
コマンド commandname は既に定義済みでなければなりません。
このコマンドは、
define
コマンドが一連のコマンド定義を読み込むのと同様にして、
end
で終わる一連のドキュメントを読み込みます。
document
コマンドの実行が完了すると、
コマンド commandname に対して help
コマンドを実行すると、
ユーザの記述したドキュメントが表示されます。
document
コマンドを再度実行することによって、
コマンドのドキュメントを変更することができます。
define
コマンドによってコマンドを再定義しても、
ドキュメントは変更されません。
help user-defined
show user
show user commandname
ユーザ定義コマンドが実行される時に、 定義内のコマンドは表示されません。 定義内の任意のコマンドにおいてエラーが発生すると、 ユーザ定義コマンドの実行が停止されます。
対話的に使われている場合には確認を求めてくるようなコマンドも、 ユーザ定義コマンドの内部で使われている場合には確認を求めることなく処理を継続します。 通常は実行中の処理に関してメッセージを表示する GDB コマンドの多くが、 ユーザ定義コマンドの中から呼び出されている場合にはメッセージを表示しません。
特別な種類のユーザ定義コマンドであるフックを定義することができます。 `hook-foo' というユーザ定義コマンドが存在すると、 ユーザが `foo' というコマンドを実行する時にはいつも、 `foo' コマンドが実行される前に (引数のない) `hook-foo' が実行されます。
仮想コマンド `stop' というものが存在します。 (`hook-stop') を定義すると、 ユーザ・プログラムの実行が停止する度に、 その定義内のコマンドが実行されます。 そのタイミングは、 ブレイクポイント・コマンドが実行される直前や、 自動表示の対象やスタック・フレームが表示される直前などです。
例えば、
シングル・ステップ実行をしている際には SIGALRM
シグナルを無視し、
通常の実行時には通常どおり処理したい場合には、
以下のように定義します。
define hook-stop handle SIGALRM nopass end define hook-run handle SIGALRM pass end define hook-continue handle SIGLARM pass end
GDB のコマンドのうち、
その名前が1つの単語から成るものには、
フックを定義することができます。
ただし、
コマンド・エイリアスにフックを定義することはできません。
フックは、
コマンドの基本名に対して定義しなければなりません。
例えば、
bt
ではなく backtrace
を使います。
フックの実行中にエラーが発生すると、
GDB コマンドは停止します。
(ユーザが実際に指定したコマンドが実行する機会を与えられる前に)
GDB はプロンプトを表示します。
既知のコマンドのいずれにも対応しないフックを定義しようとすると、
define
コマンドは警告メッセージを表示します。
GDB のコマンド・ファイルとは、 各行が GDB コマンドから成るファイルのことです。 (行の先頭が # の) コメントも含めることができます。 コマンド・ファイル内の空行は何も実行しません。 それは、 端末上での実行の場合とは異なり、 最後に実行されたコマンドの繰り返しを意味しません。
GDB を起動すると、
自動的に初期化ファイルからコマンドを読み込んで実行します。
これは、
`.gdbinit' という名前のファイルです。
GDB は、
ユーザのホーム・ディレクトリに初期化ファイルがあればまずそれを読み込み、
続いてコマンンドライン・オプションとオペランドを処理した後、
カレントな作業ディレクトリに初期化ファイルがあればそれを読み込みます。
このように動くのは、
ユーザのホーム・ディレクトリに初期化ファイルを置くことで、
コマンドライン・オプションやオペランドの処理に影響を与える
(set complaints
のような)
オプションを設定することができるようにするためです。
`-nx' オプションを使用すると、
初期化ファイルは実行されません。
モードの選択を参照。
GDB の設定のいくつかでは、 初期化ファイルは異なる名前で知られています (このような環境では、 特別な形式の GDB が他の形式の GDB と共存する必要があり、 そのために特別なバージョンの GDB の初期化ファイルには異なる名前が付られます)。 特別な名前の初期化ファイルを持つ環境には、 以下のようなものがあります。
また、
source
コマンドによって、
コマンド・ファイルの実行を要求することもできます。
source filename
コマンド・ファイルの各行は順番に実行されます。 コマンドの実行時に、 そのコマンドは表示されません。 どれか1つでもコマンドがエラーになると、 コマンド・ファイルの実行は停止されます。
対話的に使われている場合には確認を求めてくるようなコマンドも、 コマンド・ファイル内で使われている場合は確認を求めることなく処理を継続します。 通常は実行中の処理についてメッセージを表示する GDB コマンドの多くが、 コマンド・ファイルの中から呼び出されている場合にはメッセージを表示しません。
コマンド・ファイルやユーザ定義コマンドの実行中には、 通常の GDB の出力は抑止されます。 唯一出力されるのは、 定義内のコマンドが明示的に表示するメッセージだけです。 本節では、 ユーザが希望するとおりの出力を生成するのに役に立つ3つのコマンドについて説明します。
echo text
echo This is some text\n\ which is continued\n\ onto several lines.\nは
echo This is some text\n echo which is continued\n echo onto several lines.\nと同じ出力をもたらします。
output expression
output/fmt expression
print
コマンドと同様のフォーマットを指定することができます。
詳細については、
出力フォーマットを参照してください。
printf string, expressions...
printf (string, expressions...);を実行した場合と同様に、 string の指定にしたがって表示されます。 例えば、 次のようにして2つの値を 16 進数で表示することができます。
printf "foo, bar-foo = 0x%x, 0x%x\n", foo, bar-fooフォーマットを指定する文字列の中で使えるバックスラッシュ・エスケープ・シーケンスは、 バックスラッシュとそれに続く単一文字から構成される簡単なものだけです。
GDB でデバッグ中のプログラムのソース・ファイルを GNU Emacs を使って参照(および編集)するための特別なインターフェイスが提供されています。
このインターフェイスを使うには、 Emacs において M-x gdb コマンドを使います。 引数としてデバッグしたい実行ファイルを指定してください。 このコマンドは、 GDB を Emacs のサブプロセスとして起動し、 新しく作成した Emacs バッファを通じて入出力を行います。
GDB を Emacs 内において使うのは、 通常 GDB を使うのとほぼ同様ですが、 2つ相違点があります。
これは、 GDB コマンドとその出力、 デバッグ対象のユーザ・プログラムによる入出力の両方に適用されます。
これは、 以前に実行したコマンド・テキストをコピーして再入力することができるので便利です。 出力された部分に関しても同様のことができます。
Emacs の Shell モードで利用可能なすべての機能を、 ユーザ・プログラムとのやりとりで使うことができます。 特に、 シグナルの送信が通常どおりにできます。 例えば、 C-c C-c で割り込みシグナルを、 C-c C-z でストップ・シグナルを発生させることができます。
GDB がスタック・フレームを表示する時にはいつでも、 Emacs がそのフレームのソース・ファイルを自動的に見つけ、 カレント行の左側の余白に矢印(`=>')を表示します。 Emacs はソース・コードを別バッファに表示し、 スクリーンを2つに分けて、 GDB セッションとソースをともに表示します。
GDB の list
コマンドや search
コマンドを明示的に使えば、
通常どおりの出力を生成することもできますが、
これらを Emacs から使う理由はおそらくないでしょう。
注意: ユーザ・プログラムの存在するディレクトリが、 ユーザのカレント・ディレクトリでない場合には、 ソース・ファイルの存在場所について GDB は簡単に混乱に陥ります。 このような場合、 ソースを表示するための追加のディスプレイ・バッファは表示されません。 GDB はユーザの環境変数
PATH
のリストを検索してプログラムを見つけ出すので、 GDB の入出力セッションは通常どおり進行します。 しかし Emacs は、 このような状況においてソース・ファイルを見つけ出すのに十分な情報を GDB から受け取りません。 この問題を回避するには、 GDB モードをユーザ・プログラムの存在するディレクトリから開始するか、 M-x gdb の引数の入力を求められた時に、 絶対パスでファイル名を指定します。Emacs の既存の GDB バッファから、 デバッグ対象をどこか他の場所にあるプログラムに変更するのに GDB の
file
コマンドを使うと、 同様の混乱の発生することがあります。
デフォルトでは、
M-x gdb は `gdb' という名前のプログラムを呼び出します。
別の名前で GDB を呼び出す必要がある場合
(例えば、
異なる設定の GDB を別の名前で持っているような場合)
は、
Emacs の gdb-command-name
という変数を設定します。
例えば
(setq gdb-command-name "mygdb")
(を ESC ESC に続けて入力するか、
*scratch*
バッファ、
もしくは `.emacs' ファイルに入力することで)
Emacs は gdb
の代わりに「mygdb
」という名前のプログラムを呼び出します。
GDB の I/O バッファでは、 標準的な Shell モードのコマンドに加えて、 以下のような特別な Emacs コマンドを使うことができます。
step
コマンドのように、
ソース行を1行実行します。
さらに、
カレントなファイルと位置を示すために表示ウィンドウを更新します。
next
コマンドのように、
関数呼び出しをすべてスキップして、
現在の関数内の次のソース行まで実行を進めます。
さらに、
カレントなファイルと位置を示すために表示ウィンドウを更新します。
stepi
コマンドのように、
1命令を実行します。
必要に応じて表示ウィンドウを更新します。
nexti
コマンドを使って、
次の命令まで実行します。
必要に応じて表示ウィンドウを更新します。
finish
コマンドのように、
選択されたスタック・フレームを終了するまで実行を継続します。
continue
コマンドのように、
ユーザ・プログラムの実行を継続します。
注意: Emacs v19 では、
このコマンドは C-c C-p です。
up
コマンドのように、
数値引数によって示される数だけ上位のフレームに移動します
(The GNU Emacs Manual の `Numeric Arguments' を参照 )。
注意: Emacs v19 では、
このコマンドは C-c C-u です。
down
コマンドのように、
数値引数によって示される数だけ下位のフレームに移動します。
注意: Emacs v19 では、
このコマンドは C-c C-d です。
disassemble
への引数を C-x & で読みとります。
gdb-print-command
リストの要素を定義することによって、
これをさらにカスタマイズすることができます。
これが定義されていると、
C-x & で入手した数値が挿入される前に、
それをフォーマットしたり、
処理したりすることができるようになります。
C-x & に数値引数を指定すると、
特別なフォーマット処理を必要としているという意味になり、
その数値がリストの要素を取得するためのインデックスとなります。
リストの要素が文字列の場合は、
挿入される数値は Emacs の format
関数によってフォーマットされます。
リストの要素が文字列以外の場合は、
その数値が、
対応するリスト要素への引数として渡されます。
任意のソース・ファイルにおいて、
Emacs の C-x SPC (gdb-break
) コマンドは、
ポイントの置かれているソース行にブレイクポイントを設定するよう GDB に対して指示します。
誤ってソースを表示中のバッファを削除してしまった場合に、
それを再度表示させる最も簡単な方法は、
GDB バッファの中で f
コマンドを入力して、
フレーム表示を要求することです。
Emacs 配下では、
カレントなフレームのコンテキストを表示するために必要であれば、
ソース・バッファが再作成されます。
Emacs によって表示されるソース・ファイルは、 通常どおりの方法でソース・ファイルにアクセスする普通の Emacs バッファによって表示されます。 そうしたいのであれば、 これらのバッファにおいてファイルの編集を行うこともできますが、 GDB は行番号については Emacs と情報を交換していることを頭に入れておいてください。 テキストに行を挿入したり、 削除したりすると、 GDB の認識しているソース行番号は、 ソース・コードと正しく対応しなくなってしまいます。
ユーザからのバグ報告は、 GDB の信頼性を向上させるのに重要な役割を果しています。
バグを報告することで、 その問題の解決につながり、 結果として報告者自ら利益を得ることができるかもしれません。 一方、 何の解決にもつながらないこともあります。 しかし、 いずれにしても、 バグ報告の主要な意義は、 次のバージョンの GDB をより良いものにすることで、 コミュニティ全体の役に立つという点にあります。 バグ報告は、 GDB の保守作業へのユーザからの貢献です。
バグ報告がその目的とするところを首尾よく達成できるようにするためには、 バグを修正することを可能にするような情報が提供されなければなりません。
発見した現象がバグかどうかよく分らない場合には、 以下のガイドラインを参照してください。
多くの企業や個人が GNU のソフトウェアをサポートしています。 こうしたサポート組織から GDB を入手したのであれば、 まずその組織に連絡することをお勧めします。
サポートを提供している多くの企業、 個人の連絡先情報が、 GNU Emacs ディストリビューションの `etc/SERVICE' ファイルに記載されています。
いずれにしても、 GDB のバグ報告を以下のいずれかのアドレスに送ることもお勧めします。
bug-gdb@prep.ai.mit.edu {ucbvax|mit-eddie|uunet}!prep.ai.mit.edu!bug-gdb
`info-gdb'、 `help-gdb'、 あるいは任意のニュースグループにバグ報告を送ることはしないでください。 GDB ユーザのほとんどは、 バグ報告を受け取りたいと考えてはいません。 バグ報告を受け取りたいと思っている人は、 `bug-gdb' の配信を受けるようにしている筈です。
メーリング・リスト `bug-gdb' には、 リピータとして機能する `gnu.gdb.bug' というニュース・グループがあります。 このメーリング・リストとニュース・グループは、 まったく同一のメッセージを配信しています。 メーリング・リストではなくニュース・グループにバグ報告を流そうと考える人がよくいます。 これはうまく機能するように見えますが、 1つ重大な問題があります。 ニュース・グループへの投稿では、 送信者へのメール・パスが分らないことがよくあります。 したがって、 もっと多くの情報が必要になった時に、 バグの報告者と連絡を取ることができません。 こういうことがあるので、 メーリング・リストへのバグ報告の方が望ましいのです。
最後の手段として、 バグ報告を紙に書いて下記に郵送するという方法があります。
GNU Debugger Bugs Free Software Foundation Inc. 59 Temple Place - Suite 330 Boston, MA 02111-1307 USA
役に立つバグ報告を行うための最も根本的な原則は、 すべての事実を報告するです。 ある事実を書くべきか省くべきかよく分らない場合は、 書くようにしてください。
事実が省略されてしまうことがよくありますが、 これはバグ報告者が自分には問題の原因は既に分っていると考え、 いくつかの細かい点は関係がないと仮定してしまうからです。 したがって、 例の中で使った変数の名前などは重要ではないと、 報告者は考えます。 おそらくそうかもしれません。 しかし、 完全にそうであるとも言いきれません。 メモリの参照がデタラメな場所を指しているというバグで、 それがたまたまメモリ上においてその名前が置かれている箇所から値を取り出しているということがあるかもしれません。 名前が異なれば、 そこの内容は、 バグが存在するにもかかわらずデバッガが正しく動作してしまうような値になるかもしれません。 このようなことがないよう、 特定の完全な実例を提供してください。 バグの報告者にとっては、 このようにするのが最も簡単な筈であり、 かつ、 それが最も役に立つのです。
バグ報告の目的は、 未知のバグを修正することができるようにするという点にあるということを頭に入れておいてください。 バグ報告は常に、 そのバグが以前には報告されたことがないものと想定して、 書いてください。
時々、 2、3の大雑把な事実だけを記述して、 「何か思いあたることはありますか?」と聞いてくる人がいます。 このようなバグ報告は役に立ちません。 このような報告には、 より適切なバグ報告を送るよう報告者に注意する場合を除いて、 返事をすることを拒否するよう強くお願いします。
バグを修正できるようにするためには、 報告者は以下の情報をすべて含めるべきです。
show version
コマンドで表示させることができます。
この情報がないと、
カレント・バージョンの GDB を使ってバグを探すことに意味があるのかどうかを知ることができません。
以下に、 バグ報告に必要ではない情報をいくつか列挙します。
ここでは、 GNU のコマンドライン編集のインターフェイスを説明します。
以下のパラグラフでは、 キー・ストロークを表すための表記法について説明します。
文字列 C-k は Control-K と読み、 コントロール・キーが押されたままの状態でキー k が押された時に生成される文字を表します。
文字列 M-k は Meta-K と読み、 メタ・キー (があるものとして、それ) が押されたままの状態でキー k が押された時に生成される文字を表します。 メタ・キーがない場合、 同等のキー・ストロークを、 最初に ESC キーを押し、 次にキー k を押すことで生成することができます。 どちらの手順も、 キー k をメタ化するといいます。
文字列 M-C-k は Meta-Control-K と読み、 C-k をメタ化することにより生成される文字を指します。
さらに、 いくつかのキーには名前があります。 DEL、 ESC、 LFD、 SPC、 RET、 TAB はこの付録内でも、 初期化ファイルの中でも、 各々のキーを表します (詳細については、 Readline 初期化ファイルを参照)。
しばしば対話的なセッションにおいて、 長いテキストを1行に記述した後で、 その行の先頭の単語のスペルが間違っていたことに気がつくことがあります。 Readline ライブラリは、 入力したテキストを操作するための一連のコマンドを提供しており、 これによって、 その行の大部分を入力し直すことなく、 タイプ・ミスしたところだけを修正することができます。 これらの編集コマンドを使って、 修正が必要なところにカーソルを移動させ、 テキストを削除したり、 修正テキストを挿入(insert)したりします。 その行の修正が終われば、 単に RET を押します。 RET を押すのに、 行末にいる必要はありません。 カーソルが行内のどこにあろうと、 その行全体が入力として受け付けられます。
行内に文字を入力するには、 単にその文字をタイプします。 タイプされた文字はカーソルの位置に表示され、 カーソルは1桁分右へ移動します。 1文字打ち間違えた場合は、 DEL によって後退して打ち間違えた文字を削除することができます。
時には、 本当は入力したかった文字を入力せず、 その誤りに気がつくことなく、 さらに数文字を入力してしまうということがあります。 このような場合には、 C-b によってカーソルを左に移動し、 誤りを訂正することができます。 訂正後、 C-f によってカーソルを右に移動することができます。
行の途中にテキストを追加すると、 挿入(insert)された文字のためのスペースを空けるために、 カーソルの右側にある文字が右方向に押しやられることに気がつくでしょう。 同様に、 カーソル位置にあるテキストを削除すると、 文字が削除されたために生じる空白を埋めるために、 カーソルの右側にある文字が左方向に引き戻されます。 入力行のテキストを編集するための基本中の基本操作の一覧を以下に示します。
上記の一覧は、 ユーザが入力行を編集するのに必要な最も基本的なキー・ストロークを説明したものです。 ユーザの便利を考え、 C-b、 C-f、 C-d、 DEL に加えて多くのコマンドが追加されてきました。 以下に、 行内をより迅速に動きまわるためのコマンドをいくつか示します。
C-f が1文字分先に進むのに対して、 M-f が1単語分先に進む点に注意してください。 大まかな慣例として、 コントロール・キーを使うと文字単位の操作になり、 メタ・キーを使うと単語単位の操作になります。
テキストをキル(kill)するとは、 行からテキストを削除し、 その際に、 そのテキストを後に引き出してその行内に挿入(yank)することができるように退避しておくことを指します。 あるコマンドの説明に「テキストをキル(kill)する」という記述があれば、 そのテキストを後に別の箇所 (あるいは同じ箇所) において再入手することができると考えて間違いありません。
以下に、テキストをキル(kill)するためのコマンドを一覧で示します。
次に、キル(kill)されたテキストを引き出して行内へ挿入(yank)する方法を示します。
キル(kill)コマンドを使うと、 テキストはキル・リング(kill-ring)に退避されます。 キル(kill)コマンドを任意の回数連続して実行すると、 キル(kill)されたテキストはすべて連結されて退避されます。 したがって、 挿入(yank)を行うと、 そのすべてを一気に手に入れることができます。 キル・リング(kill-ring)は個々の行に固有のものではありません。 以前入力した行においてキル(kill)したテキストを、 後になって別の行を入力している時に、 挿入(yank)することができます。
Readline コマンドには数値引数を渡すことができます。 数値引数は、 繰り返し回数として使われたり、 引数の符号として使われたりします。 通常は先に進むようなコマンドに負の数を引数として指定すると、 前に戻るようになります。 例えば、 行の先頭までのテキストをキル(kill)するには、 M-- C-k とします。
コマンドに数値引数を渡す通常の方法は、 コマンドの前にメタ化された数値を入力することです。 入力した最初の数値が、 マイナス記号(-)の場合、 引数の符号は負になります。 引数を開始するために1つメタ化された数値を入力すれば、 その後は、 残りの数値を入力し、 続いてコマンドを入力することができます。 例えば、 C-d コマンドに引数として 10 を渡すためには、 M-1 0 C-d を入力します。
Readline ライブラリには GNU Emacs 風のキー・バインディングが付いていますが、 ユーザが異なるキー・バインディングを使いたいということがあるかもしれません。 ユーザのホーム・ディレクトリ内の初期化ファイルにコマンドを記述することで、 Readline を使うプログラムをカスタマイズすることができます。 このファイルの名前は、 `~/.inputrc' です。
Readline ライブラリを使うプログラムが起動されると、 `~/.inputrc' ファイルが読み込まれ、 キー・バインディングが設定されます。
さらに、 C-x C-r コマンドによってこの初期化ファイルが再読み込みされるので、 ユーザが初期化ファイルに加えた変更を組み込むことができます。
`~/.inputrc' ファイルの中では、4種の構成物のみ許されます。
set
コマンドを使うことで行います。
行編集コマンドとして vi
を使いたいということを指定するには、
次のようにします。
set editing-mode vi現在のところ、 設定できる変数は極めて少ないので、 ここでそのすべてを取り上げます。
editing-mode
editing-mode
変数は、
どの編集モードを使うのかを制御します。
デフォルトでは、
GNU Readline は、
キー・ストロークが Emacs によく似ている Emacs 編集モードで起動します。
この変数は、
emacs
と vi
のどちらかに設定することができます。
horizontal-scroll-mode
On
と Off
のどちらかに設定することができます。
これを On
に設定すると、
1行のテキストの長さがスクリーン幅よりも長い場合に、
編集中の行のテキストが次の行に折り返すことなく、
同じ行の上で水平方向にスクロールするようになります。
デフォルトでは、
この変数は Off
に設定されています。
mark-modified-lines
On
に設定されると、
変更されたヒストリ行の先頭にアスタリスク(`*')が表示されます。
この変数はデフォルトでは Off です。
prefer-visible-bell
On
に設定されると、
視覚的なベル(5)
が利用できる場合には、
単に端末のベルを鳴らす代りに、
視覚的なベルを使用します。
デフォルトでは、
この値は Off
です。
Control-u: universal-argument Meta-Rubout: backward-kill-word Control-o: ">&output"上の例では、 C-u が関数
universal-argument
に割り当てられ、
C-o がその右側に記述されたマクロ
(行内に `>&output' というテキストを挿入(insert)するマクロ)
を実行するよう割り当てられます。
"\C-u": universal-argument "\C-x\C-r": re-read-init-file "\e[11~": "Function Key 1"上の例では、 C-u が (最初の例と同様) 関数
universal-argument
に、
C-x C-r が関数 re-read-init-file
に、
ESC [ 1 1 ~ が `Function Key 1' というテキストを挿入(insert)するよう、
それぞれ割り当てられています。
beginning-of-line (C-a)
end-of-line (C-e)
forward-char (C-f)
backward-char (C-b)
forward-word (M-f)
backward-word (M-b)
clear-screen (C-l)
accept-line (Newline, Return)
previous-history (C-p)
next-history (C-n)
beginning-of-history (M-<)
end-of-history (M->)
reverse-search-history (C-r)
forward-search-history (C-s)
delete-char (C-d)
backward-delete-char (Rubout)
quoted-insert (C-q, C-v)
tab-insert (M-TAB)
self-insert (a, b, A, 1, !, ...)
transpose-chars (C-t)
transpose-words (M-t)
upcase-word (M-u)
downcase-word (M-l)
capitalize-word (M-c)
kill-line (C-k)
backward-kill-line ()
kill-word (M-d)
backward-kill-word (M-DEL)
unix-line-discard (C-u)
unix-word-rubout (C-w)
yank (C-y)
yank-pop (M-y)
digit-argument (M-0, M-1, ... M--)
universal-argument ()
complete (TAB)
possible-completions (M-?)
re-read-init-file (C-x C-r)
abort (C-g)
prefix-meta (ESC)
undo (C-_)
revert-line (M-r)
vi
モード
Readline ライブラリは vi
の編集機能のフルセットを提供する訳ではありませんが、
簡単な行編集を行うのに十分な機能は備えています。
GNU Emacs 編集モードと vi
編集モードを対話的に切り替えるには、
M-C-j
(toggle-editing-mode)
コマンドを使います。
vi
モードで行入力を行う時には、
あたかも i を入力したかのように、
最初から挿入モードになっています。
ESC を押すと編集モードに替わり、
標準的な vi
の移動キーにより行内テキストを編集することができます。
k により1つ前のヒストリ行に、
j によって1つ後のヒストリ行に移動すること等ができます。
ここでは、 ユーザの見地に立って、 GNU ヒストリ・ライブラリの対話的な使い方を説明します。
ヒストリ・ライブラリは、
csh
のヒストリ展開機能に似た機能を提供します。
以下において、
ヒストリ情報を操作するための構文を説明します。
ヒストリ展開は2つの部分から構成されます。 第1の部分で、 過去のヒストリのどの行が代替処理に使用されるかが決まります。 この行をイベントと呼びます。 第2の部分で、 この行のうちどの部分がカレント行に挿入されるかが決まります。 この部分のことをワードと呼びます。 GDB は Bash シェルと同様の方法によって行をワードに分割します。 したがって、引用符によって囲まれた複数の英単語(あるいは UNIX 用語)は1つのワードとみなされます。
イベント指定子とは、 ヒストリ・リスト内のコマンド行エントリへの参照です。
!
!!
!-1
と同義です。
!n
!-n
!string
!?string
[?
]
コロン(:)がイベント指定子とワード指定子の区切り文字になります。 ワード指定子が ^、 $、 *、 % で始まる場合は、 この区切り文字は省略することができます。 ワードは行の先頭から番号が付与され、 最初のワードは0(ゼロ)番になります。
0 (zero)
n
^
$
%
?string?
検索にマッチしたワードです。
x-y
-y
は 0-y
の省略形です。
*
1-$
と同義です。
イベントの内部にワードが1つしかなくても * の使用はエラーにはなりません。
この場合には、
空の文字列が返されます。
オプションのワード指定子に続けて、 以下の修飾子を1つ以上連続して追加することができます。 個々の修飾子の前にコロン(:)を付けます。
#
h
r
e
t
p
GDB 4 には、 メインのソース・ディレクトリの下の `gdb' サブディレクトリに、 ポストスクリプトもしくは GhostScript ですぐ印刷できる、 フォーマット済みのリファレンス・カードが含まれています。 (6) ポストスクリプトもしくは Ghostscrpt を使えるプリンタがあれば、 `refcard.ps' を使ってすぐにリファレンス・カードを印刷することができます。
GDB 4 には、 リファレンス・カードのソースも含まれています。 以下のようにして、 TeX を使ってこれをフォーマットすることができます。
make refcard.dvi
GDB のリファレンス・カードは、 米国のレター・サイズの用紙にランドスケープ・モードで印刷するようにデザインされています。 レター・サイズは、 横幅が 11 インチ、 高さが 8.5 インチです。 DVI 出力プログラムへのオプションとして、 この印刷形式を指定する必要があります。
すべての GDB ドキュメントはマシン上で読むことのできる配布物の一部として提供されます。
ドキュメントは、
Texinfo フォーマットで記述されています。
これは、
単一のソースからオンライン・マニュアルとハードコピー・マニュアルを生成するのに使うドキュメント・システムです。
Info フォーマット・コマンドの1つを使ってオンライン・ドキュメントを作成することができ、
TeX
(または texi2roff
)
を使ってハード・コピーの組版ができます。
GDB は、
`gdb' サブディレクトリに、
このマニュアルのフォーマット済みのオンライン Info バージョンを含んでいます。
メインの Info ファイルは `gdb-version-number/gdb/gdb.info' で、
同じディレクトリにある `gdb.info*' にマッチする従属ファイルを参照します。
必要であれば、
これらのファイルを印刷したり、
任意のエディタで表示して読むこともできます。
しかし、
これらのファイルは、
GNU Emacs の info
サブシステムや GNU Texinfo の一部として配布されるスタンドアロンの info
プログラムを使って読む方が簡単でしょう。
これらの Info ファイルを自分でフォーマットしたいのであれば、
texinfo-format-buffer
や makeinfo
のような Info フォーマット・プログラムが必要になります。
makeinfo
がインストールされていて、
GDB ソース・ディレクトリのトップ・レベル
(バージョン 4.17 では `gdb-4.17')
にいる場合は、
以下のようにして Info ファイルを作成することができます。
cd gdb make gdb.info
このマニュアルのコピーの組版を行い印刷するには、 TeX、 TeX の DVI 出力ファイルを印刷するプログラム、 および Texinfo 定義ファイル `texinfo.tex' が必要です。
TeX は組版プログラムです。 TeX は直接ファイルを印刷しませんが、 DVI ファイルと呼ばれるものを生成します。 組版されたドキュメントを印刷するには、 DVI ファイルを印刷するプログラムが必要です。 システム上に TeX がインストールされていれば、 DVI ファイルを印刷するプログラムも入っている可能性があります。 印刷に使われるコマンドの正確な名前はシステムにより異なります。 lpr -d が一般によく使われます。 また (ポストスクリプト・プリンタでは) dvips がよく使われます。 DVI プリント・コマンドを使う際には、 ファイル名に拡張子をつけない、 もしくは、 `.dvi' という拡張子をつける必要があるかもしれません。
また、 TeX は `texinfo.tex' という名のマクロ定義ファイルを必要とします。 このファイルは TeX に対して、 Texinfo フォーマットで記述されたドキュメントをどのようにして組版するかを教えます。 TeX は自分自身では、 Texinfo ファイルを読むことも組版することもできません。 `texinfo.tex' は GDB と一緒に配布されており、 `gdb-version-number/texinfo' ディレクトリにあります。
TeX と DVI 印刷プログラムがインストールされていれば、 このマニュアルを組版し、 印刷することができます。 まずメインのソース・ディレクトリの下の `gdb' サブディレクトリ (例えば、`gdb-4.17/gdb') に移動し、 以下を実行します。
make gdb.dvi
GDB にはインストールのための準備手続きを自動化する configure
スクリプトがついてきます。
configure
を実行後、
make
を実行することで gdb
を作成することができます。
GDB ディストリビューションには、 GDB を作成するのに必要なすべてのソース・コードが、 単一のディレクトリの下に収められています。 このディレクトリの名前は通常、 `gdb' の後ろにバージョン番号を付加したものです。
例えば、 バージョン 4.17 の GDB ディストリビューションは、 `gdb-4.17' というディレクトリに収められています。 このディレクトリには、 以下のものが含まれます。
gdb-4.17/configure (およびサポート・ファイル)
gdb-4.17/gdb
gdb-4.17/bfd
gdb-4.17/include
gdb-4.17/libiberty
gdb-4.17/opcodes
gdb-4.17/readline
gdb-4.17/glob
gdb-4.17/mmalloc
GDB の設定と構築を行う最も簡単な方法は、
`gdb-version-number' ソース・ディレクトリから configure
を実行することです。
ここでの例では、
このディレクトリは `gdb-4.17' です。
もしまだ `gdb-version-number' ソース・ディレクトリにいないのであれば、
まずそこに移動してください。
続いて configure
を実行します。
GDB が実行されるプラットフォームの識別子を引数として渡します。
例えば、 以下のようにします。
cd gdb-4.17 ./configure host make
ここで、
host は GDB が実行されるプラットフォームを識別する識別子です。
例えば `sun4' や `decstation' 等です
(多くの場合 host は省略することができます。
この場合 configure
はユーザのシステムを調べることによって正しい値を推定しようとします)。
`configure host' の実行後 make
を実行することで、
`bfd'、
`readline'、
`mmalloc'、
`libiberty' の各ライブラリが構築され、
最後に gdb
自体が構築されます。
設定されたソース・ファイルやバイナリは、
対応するソース・ディレクトリに残されます。
configure
は Bourne シェル
(/bin/sh
)
のスクリプトです。
ユーザが別のシェルを実行していて、
システムがこのことを自動的に認識してくれない場合は、
明示的に sh
にスクリプトを実行させる必要があるかもしれません。
sh configure host
バージョン 4.17 のソース・ディレクトリである `gdb-4.17' のように配下に複数のライブラリやプログラムのソース・ディレクトリを含むディレクトリから configure
を実行すると、
configure
は配下にあるそれぞれのディレクトリのための設定ファイルを作成します
(`--norecursion' オプションによって、
そうしないよう指定した場合は別です)。
GDB ディストリビューションの中の特定のサブディレクトリを設定したいだけの場合には、
そのサブディレクトリから configure
スクリプトを実行することができます。
ただし、
configure
スクリプトへのパスを必ず指定してください。
例えば、
バージョン 4.17 では、
bfd
サブディレクトリだけを設定するには以下のようにします。
cd gdb-4.17/bfd ../configure host
gdb
はどこにでもインストールできます。
あらかじめ固定されたパスは1つもありません。
ただし、
ユーザのパスにある
(`SHELL' 環境変数により指定される)
シェルが誰にでも読み込み可能であることを確かめる必要があります。
GDB はシェルを使ってユーザ・プログラムを起動するということを憶えておいてください。
子プロセスが読み込み不可のプログラムである場合、
システムによっては、
GDB がそれをデバッグするのを拒否します。
いくつかのホスト・マシンやターゲット・マシン用の GDB を実行したい場合、
ホストとターゲットの個々の組み合わせ用にコンパイルされた異なる gdb
が必要になります。
configure
には個々の設定をソース・ディレクトリにではなく個別のサブディレクトリに生成する機能があり、
このようなことが簡単にできるように設計されています。
ユーザの使っている make
プログラムに `VPATH' 機能があれば
(GNU make
にはあります)、
これら個々のディレクトリにおいて make
を実行することで、
そこで指定されている gdb
プログラムを構築することができます。
個別のディレクトリにおいて gdb
を構築するには、
ソースの置かれている場所を指定するために `--srcdir' オプションを使って configure
を実行します
(同時に、
ユーザの作業ディレクトリから configure
を見つけるためのパスも指定する必要があります。
もし、
configure
へのパスが `--srcdir' への引数として指定するものと同じであれば、
`--srcdir' オプションは指定しなくてもかまいません。
指定されなければ同じであると仮定されます)。
例えば、 バージョン 4.17 で Sun 4 用に別のディレクトリにおいて GDB を構築するには、 以下のようにします。
cd gdb-4.17 mkdir ../gdb-sun4 cd ../gdb-sun4 ../gdb-4.17/configure sun4 make
configure
が、
別の場所にあるソース・ディレクトリを使って、
ある設定を構築する際には、
ソース・ディレクトリ配下のディレクトリ・ツリー
(と同じ名前で)
同じ構造のディレクトリ・ツリーをバイナリ用に作成します。
この例では、
Sun 4 用のライブラリ `libiberty.a' は `gdb-sun4/libiberty' ディレクトリに、
GDB 自身は `gdb-sun4/gdb' にそれぞれ作成されます。
いくつかの GDB 設定を別々のディレクトリに構築する理由としてよくあるのが、
クロス・コンパイル環境
(そこでは、
GDB はホストと呼ばれるあるマシン上で動作し、
ターゲットと呼ばれる別のマシンで実行されているプログラムをデバッグします)
用に GDB を設定する場合です。
クロス・デバッグのターゲットは、
configure
に対する `--target=target' オプションを使って指定します。
プログラムやライブラリを構築するために make
を実行するときには、
設定されたディレクトリにいなければなりません。
これは、
configure
を実行した時にいたディレクトリ
(もしくは、そのサブディレクトリの1つ)
です。
configure
が個別のソース・ディレクトリに生成した Makefile
は再帰的に呼び出されます。
`gdb-4.17'
(あるいは、
`--srcdir=dirname/gdb-4.17' により設定された別のディレクトリ)
のようなソース・ディレクトリにおいて make
を実行すると、
必要とされるすべてのライブラリが構築され、
続いて GDB が構築されることになります。
複数のホストもしくはターゲットの設定が、
異なる複数のディレクトリに存在する場合、
(例えば、
それらが個々のホスト上に NFS マウントされていれば)
並行して make
を実行することができます。
複数の設定が互いに干渉しあうということはありません。
configure
スクリプトにおけるホスト、
ターゲットの仕様は、
3つの名称部分により構成されるものですが、
あらかじめ定義された別名もいくつかサポートされています。
完全名は、
以下のようなパターンの3つの情報部分を持ちます。
architecture-vendor-os
例えば、
--target=target
オプションの target の部分に、
あるいは、
ホストを指定する引数 host として、
sun4
という別名を使うことができます。
これと同等の完全名は `sparc-sun-sunos4' です。
GDB についてくる configure
スクリプトには、
サポートされているすべてのホスト名、
ターゲット名、
別名を問い合わせするための機能はありません。
configure
は Bourne シェル・スクリプトの config.sub
を呼んで、
省略名を完全名に対応付けします。
これを使って、
省略名の意味がユーザの推測したものとあっているかどうかをテストすることもできます。
以下に例を示します。
% sh config.sub sun4 sparc-sun-sunos4.1.1 % sh config.sub sun3 m68k-sun-sunos4.1.1 % sh config.sub decstation mips-dec-ultrix4.2 % sh config.sub hp300bsd m68k-hp-bsd % sh config.sub i386v i386-unknown-sysv % sh config.sub i786v Invalid configuration `i786v': machine `i786v' not recognized
config.sub
も GDB ディストリビューションの一部としてソース・ディレクトリ
(バージョン 4.17 では、`gdb-4.17')
に入っています。
configure
オプション
以下に、
GDB を構築する上で最もよく役に立つ configure
のオプション、
引数の要約を示します。
configure
には、
ここには挙げられていないオプションもいくつかあります。
configure
に関する完全な説明については、
See Info file `configure.info', node `What Configure Does'。
configure [--help] [--prefix=dir] [--srcdir=dirname] [--norecursion] [--rm] [--target=target] host
`--' ではなく単一の `-' でオプションを始めることもできますが、 `--' を使うとオプション名を省略することができます。
--help
configure
の実行方法の簡単な要約を表示します。
-prefix=dir
--srcdir=dirname
make
もしくは VPATH
機能を持つほかの make
を使用する必要があります。configure
は設定に固有のファイルをカレント・ディレクトリにおいて書き込みますが、
dirname ディレクトリにあるソースを使うように、
それらのファイルを調整します。
configure
は dirname ディレクトリの配下のソース・ディレクトリに対応するディレクトリを作業ディレクトリの下に作成します。
--norecursion
configure
が実行されたディレクトリのみを設定します。
サブディレクトリまで含めて設定することはしません。
--rm
--target=target
host ...
configure
はこれ以外のオプションも受け付けます。
しかし、
それは他の GNU ツールを再帰的に設定する場合に問題が発生しないようにするためです。
ここに挙げたオプションだけが、
GDB およびその支援ライブラリに影響を与えます。
Jump to: # - $ - . - / - : - @ - a - b - c - d - e - f - g - h - i - j - k - l - m - n - o - p - q - r - s - t - u - v - w - x - z - {
#
in Modula-2
$
$$
$_
and info breakpoints
$_
and info line
$_
, $__
, and value history
breakpoint
subroutine, remote
heuristic-fence-post
(MIPS)
remotedebug
protocol
remotedebug
, MIPS protocol
retransmit-timeout
, MIPS protocol
target remote
target remote
timeout
, MIPS protocol
vi
style command editing
This document was generated on 31 August 1998 using the texi2html translator version 1.52.